[Mayur021]

Closes item 1 of #27.

What was wrong

_api already looped three times, but only a 403 ever continued the loop. A 5xx raised on the first attempt, and URLError was not caught at all, which is the case that matters: urlopen(req, timeout=15) raises URLError on a socket timeout, a DNS failure, a reset or a TLS abort, so that one propagated straight out of the loop. URLError was not even imported.

_count_maintainer_merged alone walks up to ten PR-detail calls for a single candidate, paced half a second apart, and the run makes more calls besides. One blip anywhere in that walk ended the whole check.

Since #46 that no longer mislabels anyone, which was the needs-review:UNKNOWN symptom reported in #27. It now surfaces as CheckExecutionError and the action exits non-zero, correctly. But a single transient network blip still fails a contributor check that would have succeeded on a retry, and that is item 1.

What this does

Extends the existing loop to cover the transient cases, with full-jitter exponential backoff capped at 60s, and keeps everything else reporting as itself:

Response	Behaviour
404	return None on the first attempt, never retried
403 + Retry-After	honoured, clamped to 5-60s, as before
403 after the bound	raises, and now says it was a rate limit
5xx	backs off, then raises as that status (was: raised immediately)
URLError	backs off, then raises as a network error (was: uncaught)
any other status	raises on the first attempt, unchanged

The attempt bound stays at three. 404 moved above the 403 branch so the "an answer, not a failure" case is the first thing the handler decides; the codes are distinct so that is a readability change, not a behavioural one.

On your constraint that a genuine 404 or a rate-limit answer still reports as itself: 404 never enters the retry path, and each exhausted path now prints a line naming its own cause before re-raising. That last part is load-bearing rather than cosmetic. _run_check in contributor_check_action.py takes stderr.strip().splitlines()[-1] as the CheckExecutionError detail, so the last stderr line is what a maintainer reads. Upstream's 403 path raised silently after its third attempt, which meant an exhausted rate limit reached the maintainer as a bare exited 1, with nothing to say whether to wait or re-run.

Vendored-copy integrity

Taking your go-ahead for a declared second modification. contributor_check.py moves out of the checksum table in vendor/agt/README.md and out of the sha256sum -c list in the workflow. The other three files stay hash-pinned and the integrity job still fails if they move.

README.md now records both modifications with a behaviour table, and the "Updating" section no longer reads as a sync point against upstream. Per your note there is no upstream offer to AGT: that copy is owned here now.

Tests

24 pass, 8 new in tests/test_api_retry.py. Both outcomes of each transient path, the 404 short-circuit, the attempt bound on every exhausted path, and the backoff cap.

They were written against a mutated source rather than just run green, because a retry test that still passes with the retry removed is worth nothing. Eight mutations, each caught by at least one test:

Mutation	Tests failing
5xx retry disabled	2
URLError retry disabled	2
404 early return removed	1
retry bound widened	3
backoff cap removed	1
rate-limit cause line removed	1
5xx cause line removed	1
network cause line removed	1

Four of those tests were weak on the first pass and the sweep is what showed it. The three cause-line tests asserted a substring that the per-attempt "retrying in Xs..." messages also contain, so they passed with the final line deleted. The backoff test only evaluated attempts 0-2, where the raw curve is 1-4s and a 60s cap cannot bind either way.

One note for the record. Widening the range on the loop changes no observable behaviour, because the decision to retry is governed by last = _RETRY_MAX_ATTEMPTS - 1 and every branch at attempt == last raises, so the extra iterations are unreachable. That mutant survives by being equivalent, not by being uncovered. The bound that the tests do pin is last.

Items 2 and 3 of #27 are untouched here.

[Mayur021]

Flagging the two red checks, because neither comes from this branch.

Policy: Awaiting maintainer review is the gate doing its job.

Contributor Reputation Check / check is the one worth a look. It runs on pull_request_target, and its checkout step logs 79cf0e4, so it executed the copy on main rather than anything in this PR. The error is contributor_check.py exited 1: urllib.error.HTTPError: HTTP Error 422.

It also looks like the first time that path has run on a real pull request since vendoring. The run on #46 predates the vendored copy landing on main, and the job's if: skips the maintainer account, so #36, #44 and #48 never exercised it.

What I cannot tell you is which call returned the 422, because the error carries no endpoint. I ran the same profile check locally against the same username and target repo and every call came back 200, so it does not reproduce with a user token, which points at the Actions identity rather than the query shape.

I have kept it out of this PR rather than widening the scope. The one-line improvement is that _api should name the path it was calling when it raises, which would have turned that log line into a diagnosis. Happy to open a separate issue, or to fold it into item 2 if you would rather keep everything on #27.