Repository navigation
Retry a request gh sent and got no answer to - #10
Merged
Merged
Conversation
gh_api retries a busy or unreachable API, but the only status-less failure it counted as unreachable was gh's "error connecting to" line, which gh prints for a failed name lookup alone. Every other request left unanswered - a dial or TLS handshake that timed out, a reset connection, a proxy that refused - prints Go's error for it instead, such as Get "https://api.github.com/...": dial tcp 20.29.134.17:443: i/o timeout and that failed on the first attempt. On a clock host it happened to the mark read, so the tick sent nothing and exited 1, and its slot waited for the next tick. Go's error opens with the method and the quoted URL, so that shape is what counts as unanswered now, rather than a list of causes Go words many ways. A cause no retry clears, such as a refused certificate, costs only the ladder's waits before the same failure. A request that applied before its answer was lost was already retried on a timeout or a 5xx, and its callers cover that: a mark claim reads back whose blob the mark holds, a ledger create or delete takes its 422 as done, and a second dispatch of a slot is one more delivery, which the concurrency group and slot action run once. The version goes to 0.2.2.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
gh_apiretries a busy or unreachable API. For a failure with no HTTP status, though, the only form it retried was gh'serror connecting toline, and gh prints that for a failed name lookup alone. Every other request that gets no answer prints Go's error for it, and that failed on the first attempt:Over two days, a clock host logged both of these on the mark read. A tick that cannot read the marks sends nothing and exits 1, so each one pushed a slot back to the next tick. The same host also logged a stale-mark delete failing this way. Pruning is housekeeping, so that one didn't fail its tick.
Go's error opens with the method and the quoted URL (
Get "<url>":). A status-less failure in that shape now counts as unanswered and goes through the existing retry ladder. I matched the shape rather than a list of causes, because Go words those many ways. A cause no retry clears, such as a refused certificate, costs only the ladder's waits before the same failure.Retrying a request that may already have applied isn't new.
gh_apialready retried one after a timeout or a 5xx, and the callers cover it:Tests:
HTTPS_PROXYat a closed port, it prints Go's error for GET, DELETE and GraphQL POST. With the proxy at a name that doesn't resolve, it printserror connecting to.I ran these on a Mac: the unit tests on Python 3.14,
ruff format --check,ruff checkandmypy. I didn't run the live check locally; CI runs it.The version goes to 0.2.2.