feat(action): retry the same credential once on a genuine short-lived rate limit - #60
Merged
Merged
Conversation
… rate limit
Add retry_on_rate_limit (on by default) and rate_limit_retry_wait_seconds (default 60).
After any credential attempt fails, a new "Rate-limit retry gate" step reads that
attempt's own execution output and checks whether the failure was a 429 whose message
does not name a multi-day-scale reset ("weekly limit", "monthly limit", and similar).
A plain 429 with no such wording is treated as a genuine, short-lived rate limit worth
waiting out; one that does name a quota reset is left to fall straight through to the
next configured credential exactly as before, since no amount of waiting inside this
job would clear it.
When the gate judges a failure retryable, this waits the configured seconds and
reruns that exact same credential once via a new retry step, before falling through
to the next credential (or giving up) only if that retry also fails. This sits
alongside the existing credential-fallback chain rather than replacing it: fallback
already moves to a different account on any failure regardless of cause, which is
correct for a quota exhaustion but wastes a momentarily-throttled credential, or
fails a run outright with no fallback configured, on a rate limit a short wait
would have cleared.
Implemented as one more statically-unrolled gate-and-retry pair per credential slot
(a composite action has no native loop, matching how the existing fallback chain is
itself implemented), and wired through action.yml's validation, the "Resolve Claude
Code result" winner selection across every attempt/retry slot, and the three
reusable workflows' passthrough inputs.
|
❌ Claude's run did not complete (outcome: failure). View job run |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
🗜️ Headroom context compression
|
|
🎉 This PR is included in version 1.12.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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
1 participant
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.
Adds
retry_on_rate_limit(on by default) andrate_limit_retry_wait_seconds(default 60).Falling through to the next configured credential is the right response to a hard quota exhaustion (an account's weekly/monthly usage cap, which no wait inside this job can lift), but the wrong one for a genuine short-lived rate limit (too many requests in a short window, which a brief wait clears) -- moving to a different account for that either burns a fallback credential unnecessarily or, with none configured, fails a run a short wait would have completed.
After any credential attempt fails, a new "Rate-limit retry gate" step reads that attempt's own
execution_fileoutput and checks whether the failure was a 429 whose message does not name a multi-day-scale reset ("weekly limit", "monthly limit", and similar). A plain 429 with no such wording is treated as a genuine rate limit worth waiting out; one that does name a quota reset falls straight through to the next credential exactly as before. When retryable, this waitsrate_limit_retry_wait_secondsand reruns that exact same credential once, before falling through only if the retry also fails.This is a single, bounded retry per credential slot, not a configurable count -- like the fallback chain itself, a composite action has no native loop, so it's implemented as one more statically-unrolled gate-and-retry pair per slot (
retry_gate_N/attempt_N_retry), mirroring how the existingattempt_1..5fallback chain is itself built. Wired throughaction.yml's input validation, every attempt's ownif:condition (now checking whether either the attempt or its retry succeeded before falling through), the "Resolve Claude Code result" winner selection across all ten attempt/retry slots, and the three reusable workflows' passthrough inputs.Verified statically (no live credential available to exercise this end-to-end right now -- see below): YAML parses, every embedded bash script passes
bash -n,actionlintagainst both the three real reusable workflows and a syntheticworkflow_callwrapper around the composite action's own steps reports zero errors (only pre-existing shellcheck style notes), and prettier/eslint are clean.Prompted by triaging PR #58's own
claude-reviewdogfooding check, which failed on a real weekly-quota 429 -- confirmed to be quota exhaustion, not a genuine rate limit, so this feature wouldn't have changed that specific outcome, but surfaced the gap.