fix: End a sweep on an error that holds for the whole run

[mpaulosky]

Closes #179.

Why

Claude Review on mpaulosky/TicketManager#193 (the #178 re-Apply): #178 made a sweep catch each PR's error and carry on. That's right for a 5xx on one read, but a 401 (revoked RELEASE_PR_PAT), a 403/429 rate limit or a GraphQL RATE_LIMITED error fails every later call too, and GitHub asks callers to stop on a rate limit.

What changed

• pr-automerge.yml (Template and dotfiles' copy): evaluate rethrows those errors, which ends the run as before fix: Make a sweep's one update after its merges, and only if it merged none #178. Other errors are still logged per PR and fail the run once the sweep is done.
• Tests: a sweep stops at each of the four.
• references/automerge.md notes the split.

Testing

test.sh passes (142 auto-merge tests).

🤖 Generated with Claude Code

[github-actions]

Claude Review

The PR changes the sweep in pr-automerge.yml (the repo copy and the template copy are identical). Errors that hold for the whole run now end the sweep straight away: a 401, 403 or 429 status, or a GraphQL RATE_LIMITED error. Any other error from one PR is still logged, and the sweep goes on to its update. It also adds a test for each of the four error kinds and a line in automerge.md.

Verdict: the idea is sound, but endsRun counts every 403 as a rate limit. GitHub also returns 403 for problems that affect only one PR. When that happens, the sweep is cut short before its update, which is the stall #178 fixed. The tests only cover a rate-limit 403, so they don't catch this.

I read the INDEX and the single piece, 001.diff, which holds all four files. There is no AGENTS.md or CLAUDE.md in the repo. I didn't read any unchanged code: mergeIfReady and the code that ends a sweep are not covered. So which per-PR calls can return 403 is based on how the GitHub REST API behaves, not on this repo's code. I also didn't check line numbers against the checked-out files. They come from the diff's hunk headers, and 001.diff gives both workflow copies the same blob hashes, so 1007 applies to both.

[github-actions]

Claude Review

What the PR changes: PR #180 changes when an error ends an automerge sweep early. A 403 now ends the run only when it's a rate limit: x-ratelimit-remaining: 0, a retry-after header, or "rate limit" in the error message. 401, 429 and GraphQL RATE_LIMITED errors still end the run at once. Any other 403 (a locked PR, a branch restriction) counts as that one PR's error, so the sweep logs it, carries on to its update, and then fails the run.

The change is made the same way in .github/workflows/pr-automerge.yml and in the template copy, which have the same blob hashes, so the two stay in sync. It comes with parameterised tests (each run-ending error stops the sweep before PR 9 is read and makes no update; a plain 403 still lets the update for PR 7 happen) and a docs note in references/automerge.md.

What I checked:

• The rate-limit test fits how Octokit reports errors. RequestError puts lower-cased string headers on error.response.headers. GitHub sends x-ratelimit-remaining: "0" and/or retry-after on primary and secondary rate-limit 403s. Both of its usual messages ("API rate limit exceeded…", "You have exceeded a secondary rate limit…") match /rate limit/i. A GraphQL rate limit comes back as HTTP 200 with errors[].type === "RATE_LIMITED", which GraphqlResponseError exposes as error.errors.
• Narrowing the 403 check costs nothing. Every 403 left out of endsRun (for example "Resource not accessible by integration") goes back to the earlier per-PR handling: the sweep continues and the run still fails at the end.
• Missing fields don't cause errors. endsRun reads every field defensively (?., ??), so an error with no response or message won't throw a TypeError that would hide the original error.
• The test helper's new try/catch doesn't hide anything. It only adds an observed property and rethrows the same error object, so existing tests that expect a rejection keep the same error.

Not verified: I didn't open the unchanged code around the change, so these points rest on what the diff shows:

• reads is in scope in the test helper (the diff uses it, but the helper's return statement doesn't include it).
• mergeIfReady, and the step that evaluates the candidate again before the update, let errors reach evaluate instead of handling them internally.

The PR's own tests would catch a problem with the first point.

Coverage: I read the single piece, 001.diff, in full. It holds all 4 files and none were excluded. The repository has no CLAUDE.md or AGENTS.md.

Verdict: I found nothing that should block the merge; the change looks correct and is well tested.

No findings.