Development record
A 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.
issueresolvedminoriss-2610090642376032
A 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.
2026-10-15, evidence from #1011: the merge queue removed it for failed_checks at 07:48Z (the ubuntu race step hit its 30-minute limit; run 38697714235), and that removal also cleared auto-merge. So "not armed and not queued" has two causes, a dropped arming and a failed queue run. A watch, or abcd land on a re-run, should read the timeline's RemovedFromMergeQueueEvent reason and name it before arming again, rather than re-queue silently into the same failure.
Grounds
- pursued: an armed pull request no longer sits CLEAN outside the queue or out of it unseen; shown wrong if a later run again finds a landed pull request unqueued at CLEAN for longer than the grace, or dropped from the queue with no report naming the failed check
Frontmatter
| id | iss-2610090642376032 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610090642376032-a-pull-request-the-implement-loop-lands.md
open on GitHub ↗ · commit history ↗
mentions6
- iss-2609012313465609Measured on 2026-09-01 with thirteen auto-merge pull requests in flight: each one pays two full CI cycles before it lands, and the macOS check job alone takes about 13 minutes (ubuntu 9). Cycle one: the pull request is armed, main moves, the strict up-to-date policy makes it BEHIND, the keep-current script updates the branch, and the full CI re-runs on the updated head before the pull request is CLEAN enough to enter the merge queue. Cycle two: the merge queue runs the full CI again on the merge group. Every merge moves main and knocks the not-yet-queued pull requests back to cycle one, so a batch of thirteen cost roughly twenty-six 13-minute cycles serialised in ALLGREEN groups, and a one-line record change waited an hour. The maintainer asks how to speed the gates up, for example by running them locally first. Directions, none adopted: (1) local-first is already built and not wired on every account: make preflight is the pre-push gate and .githooks/pre-push runs it, but core.hooksPath is unset on at least one active account, so nothing runs before a push; wire it at ahoy install (an owned ConfigChange) and record which accounts have it; note that a local pass shortens nothing on the forge, it only stops red pushes. (2) Run the full matrix once, in the queue: on the pull_request event run the fast lane only (format, record gates, ubuntu build and test) and keep the macOS leg, the race lane and the smoke harness for the merge_group event, which already runs everything; the CI classifier that stands macOS down for docs-only changes shows the seam exists. (3) Cache the Go build and test cache across runs (actions/setup-go cache keyed on go.sum) and check whether the macOS job's 13 minutes is test time or cold-build time. (4) Let the queue batch: min_entries_to_merge_wait_minutes is 0, so each pull request tends to get its own group; a short wait lets several share one CI run. (5) The strict policy is the multiplier and was kept on 2026-09-01 (iss-2609012202237613); revisit only with the duplicate-id gate argument answered.
- iss-2610110401224302A 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.
- iss-2610150524246898Ready pull requests reach the merge queue one at a time, so a queue that can build four entries at once tests one. On 2026-10-15 abcd's own queue was configured to build up to four entries (max_entries_to_build 4), but the coordinator queued each pull request only after the previous one merged, through hand-run watchers. With each queue run taking 25 to 40 minutes, three ready pull requests cost about two hours instead of about forty minutes. abcd's land step arms auto-merge for a build lane, which lets the queue batch, but landings outside the loop have no such step, and iss-2610090642376032 already records that even a lane's arming can leave a pull request unqueued. The product thinker asked (2026-10-15) for queueing ready work together to be the default for every abcd-managed repository, toggled in config. Bound by the security standard rule: abcd adds the queueing, never changes how the repository's queue is configured.
- iss-2610150656282243abcd land and the build loop decide whether a merge is held for a person's approval (ruling AM1) from the committed ruleset mirror under .abcd/work/rulesets/, never from the forge's live rules. A mirror that has gone stale, saying an approval is required when the forge no longer requires one, lets abcd arm a merge that no person gates. Found by the Opus security reviewer of the abcd land change on 2026-10-15; the loop has the same reading, so this predates abcd land. Route exists without abcd: no, the mirror-based decision is abcd's, so abcd fixes it.
- itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kind
- spc-2609212015054359drain-ledger-triage