v2.5.2 ·
A 429 in a file list is not a rate limit
On October 14 autopilot stopped its own merge queue over a test file.
The pull request was green and mergeable. Before merging, autopilot brings the branch up to date with main, and git printed the usual list of changed files. One line read packages/cli/test/autopilot-gitlab.test.ts | 429 +++. Autopilot checked every command's output for a 429, took that line for GitHub telling it to slow down, and backed off. It had made the merge commit but had not pushed it.
Five minutes later it came back, saw main already in the branch, and went straight to the merge. It asked GitHub to merge a commit GitHub had never seen. GitHub refused, the queue halted, and the watch view said a person was needed. There was nothing for a person to decide.
Then it got funnier. I wrote the bug up as a backlog item and asked autopilot to fix it. The item's title says "a '429' in git's diffstat reads as a rate limit", so the moment autopilot read the next item from the backlog, it backed off again. It waited 5, 10, 20, then 40 minutes and never started. The bug was guarding itself. I fixed this one by hand.
What changed
Autopilot now reads a rate limit only where a host can send one. That means gh, glab, and the error output of git push, fetch and pull. Local git commands are never read. A merge, a status check or a diff runs on my machine, and nothing on my machine rate-limits me.
A bare 429 no longer counts anywhere. It has to come with the host's wording: "rate limit", HTTP 429, 429 Too Many Requests. A branch named after this very item, with 429 in it, shows up in every push, and pull request number 429 is not far off. Neither should stop a run.
The backlog read and the release step no longer count at all, because both print text I wrote. Item titles and commit subjects are allowed to talk about rate limits.
The second half is a check before the merge. If the branch already contains main but its head has not reached GitHub, autopilot pushes it and waits for CI on that commit, the same as after any other update. It only merges a commit GitHub has.
What it does not fix
The steps after a merge still trust that nothing throws halfway. If a real rate limit hits between the merge and the release, a person still has to finish the job, as before.
Two bugs, and the tell for both was the same. A check that looks at more output than it needs to will eventually match something it was never meant to see. The fix is in packages/cli/src/autopilot/driver.ts, with eight new tests that fail on the old code.