ARCHIVED TRAINING / brettcannon/gidgethub
brettcannon__gidgethub-174
This is a preserved training example. Membership in the current training wave has not been verified.
Problem statement
202 ACCEPTED considered as error
From here, it looks like the only correct HTTP status codes are 200 OK, 201 CREATED, and 204 NO CONTENT:
https://github.com/brettcannon/gidgethub/blob/8724568f87efe1a13c8e0e2251969c1ba9940c7a/gidgethub/sansio.py#L316-L318
However, some endpoints may also return 202 ACCEPTED, like `POST /repos/{owner}/{repo}/forks`:
https://docs.github.com/en/rest/reference/repos#create-a-fork
From [RFC7231 Section 6.3.3](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.3) I read
> The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place.
> The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist
until the process is completed.
This is consistent with what the GH docs say:
> **Note**: Forking a Repository happens asynchronously. You may have to wait a short period of time before you can access the git objects. If this takes longer than 5 minutes, be sure to contact GitHub Support.
Should 202 be treated as successful instead?
Training membership
opd_e4b_pure_v6b
Task issues extracted from preserved verified_rft_messages training examples. This is not a verified current RL wave manifest.
Task and snapshot provenance
Snapshot captured 2026-11-12T17:06:59.476467+00:00 · Autoresearch-Arena/gemma-4-developer-agent
{
"datasets": [
"opd_e4b_pure_v6b"
],
"examples": 1,
"instance_id": "brettcannon__gidgethub-174",
"problem_statement": "202 ACCEPTED considered as error\nFrom here, it looks like the only correct HTTP status codes are 200 OK, 201 CREATED, and 204 NO CONTENT:\r\n\r\nhttps://github.com/brettcannon/gidgethub/blob/8724568f87efe1a13c8e0e2251969c1ba9940c7a/gidgethub/sansio.py#L316-L318\r\n\r\nHowever, some endpoints may also return 202 ACCEPTED, like `POST /repos/{owner}/{repo}/forks`:\r\n\r\nhttps://docs.github.com/en/rest/reference/repos#create-a-fork\r\n\r\nFrom [RFC7231 Section 6.3.3](https://datatracker.ietf.org/doc/html/rfc7231#section-6.3.3) I read\r\n\r\n> The 202 (Accepted) status code indicates that the request has been\r\n accepted for processing, but the processing has not been completed.\r\n The request might or might not eventually be acted upon, as it might\r\n be disallowed when processing actually takes place.\r\n\r\n> The 202 response is intentionally noncommittal. Its purpose is to\r\n allow a server to accept a request for some other process (perhaps a\r\n batch-oriented process that is only run once per day) without\r\n requiring that the user agent's connection to the server persist\r\n until the process is completed.\r\n\r\nThis is consistent with what the GH docs say:\r\n\r\n> **Note**: Forking a Repository happens asynchronously. You may have to wait a short period of time before you can access the git objects. If this takes longer than 5 minutes, be sure to contact GitHub Support.\r\n\r\nShould 202 be treated as successful instead?",
"repo": "brettcannon/gidgethub",
"source": "v2/experiments/train_data/opd_e4b_pure_v6b/verified_rft_messages.jsonl",
"source_sha256": "0f62460a9706eea5e1605255896f191ab00cb5706c5f1f2e1c293e9a718218dc"
}{
"captured_at": "2026-11-12T17:06:59.476467+00:00",
"membership": "archived training",
"membership_evidence": "Task issues extracted from preserved verified_rft_messages training examples. This is not a verified current RL wave manifest.",
"name": "Preserved post-training task archive",
"source": "Autoresearch-Arena/gemma-4-developer-agent",
"source_revision": "016496de222aaafca0d4ee4c18efc63ba616f76e",
"sources": [
{
"path": "v2/experiments/train_data/opd_e4b_cispo_v5/verified_rft_messages.jsonl",
"sha256": "a43610ad0dfb6ace95375cfae09000f41afc0338cc925af870a4ade7a9b20c4c"
},
{
"path": "v2/experiments/train_data/opd_e4b_hybrid_v3/verified_rft_messages.jsonl",
"sha256": "bd326303eb127e8e5e08f03daf97bb88d79d19709d59f3f93f348bc56686a8df"
},
{
"path": "v2/experiments/train_data/opd_e4b_onpolicy_v3/verified_rft_messages.jsonl",
"sha256": "960c680e797e823a0d3a22f4b1d5ef60a72971373d703b877340b0c9126aaf68"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v6a/verified_rft_messages.jsonl",
"sha256": "f045b7ca5b3883a1e2eaee81e1c02a4a1b53dd7b7b36e98bacb2ba5823a15148"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v6b/verified_rft_messages.jsonl",
"sha256": "0f62460a9706eea5e1605255896f191ab00cb5706c5f1f2e1c293e9a718218dc"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v7/verified_rft_messages.jsonl",
"sha256": "e37f7bd675322f3f81500b73559d60d5f602ca0537bf19f5cb06332c728c7b72"
},
{
"path": "v2/experiments/train_data/opd_e4b_pure_v7b/verified_rft_messages.jsonl",
"sha256": "b864bdc8695183433eef6e31cb8d33fad44ba3aded2170c1ade4ad5b2944ce23"
},
{
"path": "v2/experiments/train_data/opd_e4b_self_audit_v4/verified_rft_messages.jsonl",
"sha256": "0026023745afb8f3dc1c176dc7f7171157b4ad5a66656b524af218e8e19ceee6"
},
{
"path": "v2/experiments/train_data/rft_e4b_aligned_v2/verified_rft_messages.jsonl",
"sha256": "92a4515fee9d152b0d4c510ee3ce4caaaffe2003ba7584469f8027f174aab18c"
},
{
"path": "v2/experiments/train_data/rft_v1/verified_rft_messages.jsonl",
"sha256": "a42453ccd7ac7680b0a03865e8e7080bc8bf74c8d9d193b440c441ed46f8512b"
},
{
"path": "v2/experiments/train_data/rft_v2/verified_rft_messages.jsonl",
"sha256": "18f4b3bd7e651f83c6acab479c9475e3fa50dc652a384f309e97146983ac85ba"
}
]
}