sweep: stop retrying diffs GitHub refuses to serve - #49
Merged
Conversation
`gh pr diff` 406s on anything past 20k lines, and `getDiff` mapped every non-zero exit to null — so the sweep logged "will retry next sweep" and re-fetched those PRs every 60s forever. 11,055 wasted attempts on bevyl, across #8338/#8308/#8241/#8121. Raising DIFF_LINE_CAP 5k -> 20k in dd27ec5 made this reachable: GitHub's own limit is exactly 20000, so the cap can never be hit — anything that 406s is already unreviewable. Split the two failure modes. 'unreadable' still retries; 'too-large' is terminal and now says so, on the sweep path and on `stupify review <N>` (which had the same bug). Commit status stays success, matching the existing over-cap skip: there is no neutral status, and a red X would block merges on PRs we simply cannot read.
![exe-dev-github-integration[bot]](https://avatars.githubusercontent.com/in/3061187?s=60&v=4){kind=small}
Octember
added a commit
that referenced
this pull request
Jul 25, 2026
#49 only matched "diff exceeded the maximum number of lines". GitHub 406s on TWO limits — 20000 lines and 300 files — so #8338 and #8241 (both over the file cap) stayed in the retry loop after the fix, while #8308 and #8121 correctly dropped out. Match gh's stable `PullRequest.diff too_large` code, which both variants carry, and keep the prose patterns as a fallback. Both real payloads are pinned in the test.
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.
The bug
gh pr diffreturns HTTP 406 on any diff past 20,000 lines:getDiffmapped every non-zero exit tonull, so the sweep logged "couldn't read its diff from gh; will retry next sweep" and the 60s cron re-fetched forever. 11,055 wasted attempts on the bevyl VM, across #8338 / #8308 / #8241 / #8121 — and the message promised a retry that could never succeed.Raising
DIFF_LINE_CAP5k → 20k in dd27ec5 is what made this reachable: GitHub's own diff limit is exactly 20000, so the cap can never be hit. Anything that 406s is already over cap by definition.The fix
getDiffnow returns a discriminated result instead ofstring | null:unreadable— unchanged, still transient, still retried.too-large— terminal. Skipped for good, with a message that says what actually happened:The manual
stupify review <N>path had the same bug (it only said "couldn't fetch the diff") and gets the same treatment.Notes for the reviewer
success, matching the existing over-cap skip. GitHub statuses have no neutral state, anderrorwould permanently red-X every oversized PR and block merges on ones we simply cannot read.isDiffTooLargeis exported as a testable predicate, following the existingisRateLimitedpattern.This stops the retry loop and the misleading message. It does not make those 4 PRs reviewable — GitHub will not serve a >20k-line diff to anyone.