[jeffwall-curlewlabs]

gh_api retries a busy or unreachable API, but not an answer that arrived empty or cut off. gh decodes an answer before it reports a status whenever it filters one with --jq, reads a GraphQL answer, or reads a JSON error body (gh 2.101.0's processResponse; go-gh's jq.EvaluateFormatted). A short body then fails with Go's decoder error and nothing else on stderr:

unexpected end of JSON input

That counted as a refusal, so it failed on the first attempt. A clock host logged it once on the mark read: the tick sent nothing and exited 1, and the same read succeeded a few minutes later. Since gh prints no status here, the log can't say whether the answer was an error with an empty body or a success that was cut short.

Change

• A status-less failure whose message is exactly unexpected end of JSON input is now transient. The match is exact so that other status-less failures, such as a usage error, stay refusals.
• The busy ladder's waits go from 5, 20, 60 to 1, 2, 4, 8, 10, 10, 10. Most of these failures are one lost answer that the next attempt gets, and the total wait stays under a minute.
• A rate limit (a 429, or a 403 that says "secondary rate limit") has its own path now: one retry, after 60s. The old ladder's last step was 60s because that is GitHub's documented minimum wait after a secondary rate limit. The short waits would spend every retry with no chance of clearing the limit, while sending the requests GitHub warns can get an integration banned.
• gh_api takes the runner as a parameter, as it already took sleep, so the retry path is tested without a network.
• The live job's cap goes from 20 to 25 minutes. The worst case for a failing call is now about 9.75 minutes: every busy attempt times out at 60s, plus the rate-limit wait. The cap still has to hold that twice, for the check and for its cleanup.

Retrying a request that may already have applied isn't new, and the callers cover it:

• A mark claim reads back whose blob the mark holds.
• A ledger create or delete takes its 422 as done.
• A second dispatch of a slot is one more delivery, which the concurrency group and the slot action run once.

Tests

• The classifier treats the cut-off line as transient and as not a rate limit. The rate-limit lines are rate limits and not transient, and every refusal is neither.
• gh_api against a stand-in gh: a cut-off answer is retried after the first busy wait; a busy API is retried once per ladder step and then raises; a rate limit waits RATE_LIMIT_DELAY_SECONDS, is retried once, and a second one raises.
• I checked that the tests can fail. With the cut-off match removed, two tests fail. With rate limits routed through the busy ladder, the rate-limit test fails.

I ran these on a Mac: the unit tests on Python 3.14, ruff format --check, ruff check, mypy and actionlint. I didn't run the live check locally; CI runs it.

The version goes to 0.2.3.

[jeffwall-curlewlabs]

The first run's live check failed in its cleanup. A ref delete got this from GitHub:

gh: HTTP 500

It failed on the first attempt (the whole step took 39s, shorter than the busy ladder's waits). That's an older gap of the same kind as this PR's fix. When an error body holds no message gh can read, such as a 5xx with an empty or non-JSON body, gh 2.101.0 prints the status alone (processResponse falls back to HTTP %d). classify only read the gh: <message> (HTTP <status>) form, so this line came back status-less and counted as a refusal.

cce9f59 reads both forms:

• A bare 5xx now gets the busy ladder.
• A bare 404 or 422 now reaches the callers that act on those statuses as an HttpError, instead of a plain GitHubError.
• HttpError's text leaves out an empty message.

The gh: HTTP 500 line is now a case in the classifier test. Against the previous regex it reads as not transient.

Still not handled, and not seen anywhere: with --jq, a 5xx whose body is HTML would fail in gh's JSON decoder with invalid character '<' ... before gh prints any status. I left that out because nothing has logged it.