Development record
A lane's pull request can leave the merge queue without anyone being told, and its auto-merge falls off with it. On 2026-10-11 the queue removed two drain PRs. #906's queue CI was cancelled when a peer's PR was re-queued ahead of it. #903 was removed about 45 minutes after entry while its macOS check was still running. Both then sat open and unarmed. Meanwhile implement step went on reporting only 'pull request #N is not merged yet', because it reads merge state, never queue membership or the armed flag. They were found by hand an hour or more later.
A lane's pull request can leave the merge queue without anyone being told, and its auto-merge falls off with it. On 2026-10-11 the queue removed two drain PRs. #906's queue CI was cancelled when a peer's PR was re-queued ahead of it. #903 was removed about 45 minutes after entry while its macOS check was still running. Both then sat open and unarmed. Meanwhile implement step went on reporting only 'pull request #N is not merged yet', because it reads merge state, never queue membership or the armed flag. They were found by hand an hour or more later.
A second occurrence, on 2026-11-01, shows that re-arming once is not always the answer. #1315 (lane 1 of run-2610312053481114) was armed at 06:13 and queued behind #1313. The queue ran the two together and go vet failed: each branch had added a test helper named treeHashes to the same package, so the merge group declared it twice. A comment on the pull request explained the clash, but the queue removed it at 07:29 and it sat open, green and unarmed for over four hours, until the build session looked. Merging main also changed what one of its tests asserted: #1314, landed meanwhile, raised the default rows limit from 24 to 32. Each branch passed on its own, and only the combination failed. A re-arm here would have failed the same way. So whatever reads the queue's removal should also read the merge group's conclusion. Most failed groups are not code faults: iss-2610090642376032 records drops from the macOS job cap and flaky tests. So a failed group goes to a fix round only when its failing check fails again on a merge of the default branch into the lane.
Frontmatter
| id | iss-2610110401224302 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610110401224302-a-lane-pr-leaves-the-merge-queue.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2610090642376032A pull request the implement loop lands can leave the merge queue silently. Twice it sat CLEAN with auto-merge armed and never entered the queue (#837, #844; the enqueue mutation then failed with a forge error and only toggling auto-merge queued it), and four times across this run and the v0.13.2 cut a failed merge-group check (the macOS job cap, or a flaky test) dropped it from the queue (#839, #854, #867, #869) with nothing re-queuing it. The loop arms auto-merge and walks away, so a run that trusts it stalls unseen; one drop cost about 45 minutes in this run.
- iss-2611051719381143An armed pull request whose required check failed before it reached the queue stays armed and blocked. `abcd land` names the failed check only when it is run again, and the status board never does, so nothing says so between land runs and a queue watch sees an empty queue either way. This is the part before the queue. A drop from the queue is iss-2611022247147314, and retrying a drop that is not the pull request's own fault is iss-2610110401224302.