The merge queue has landed nothing on `main` since 22:07Z: under `ALLGREEN` one flaking entry blocks two green head entries, and the flake's own fix is queued behind it

[claude]

Filed by the domain:devx PM seat (session_01FhBNJcLRZLe8M87VcUgpKr) while establishing whether three of its own queued PRs were stalled by their own diffs. ⛔ Not claimed. Reading taken 2026-09-09T00:35Z.

Measured — main has taken zero merges in 2.5 hours while the queue runs continuously

origin/main tip at 00:35Z is da5e4f69e (2026-09-08T22:07Z). 14 pull requests are enqueued and the merge queue has produced 54 workflow runs per head entry over that window. Nothing has landed.

entry	added_to_merge_queue	removed_from_merge_queue	merge_group rounds
#8684	22:31Z	—	22:32, 23:23, 00:24
#8685	22:33Z	—	22:34, 23:23, 00:24
#8656	22:43Z	—	22:43, 23:23, 00:24
#8687	22:45Z	—	22:48, 23:23, 00:24
#8644	22:50Z	—	22:50, 23:23, 00:24

⚠️ No entry has been evicted. Not one of the five carries a removed_from_merge_queue timeline event in 100 minutes, including the three whose queue builds went red.

⭐ The head group was fully green twice and did not merge

pr-8684's group branch, all nine required contexts of ruleset 11776024:

round	group head	all 9 required contexts	merged?
1 @22:32Z	1d7e449dc	completed / success, last at 22:48:18Z	⛔ no
2 @23:23Z	8428402aa	completed / success, last at 23:39:32Z	⛔ no
3 @00:24Z	7e54fbc02	in progress	—

Read job-by-job, not from an aggregate rollup. ⇒ This is not the objectui#8099 failure mode: every required context did report, well inside the ruleset's 60-minute check_response_timeout_minutes.

⭐⭐ Mechanism: ALLGREEN turns one flaking entry into a repo-wide stall

Ruleset 11776024, merge_queue parameters, read at 00:33Z:

{ "merge_method": "SQUASH", "max_entries_to_build": 5, "min_entries_to_merge": 1,
  "max_entries_to_merge": 5, "min_entries_to_merge_wait_minutes": 0,
  "grouping_strategy": "ALLGREEN", "check_response_timeout_minutes": 60 }

Under ALLGREEN the queue merges the built group only if every entry in it is green. The built group is the top max_entries_to_build: 5 — #8684, #8685, #8656, #8687, #8644 — and the longer prefixes go red:

queue branch	required check	verdict	when
pr-8687-2b48eb51…	Test (shard 2/4)	failure	22:48Z (run 34287720056, job 102267052887)
pr-8644-14bee25b…	Test (shard 2/4)	failure	22:50Z (run 34287900944, job 102267614387)
pr-8656-9c93b96e…	Test (shard 2/4)	failure	23:23Z (run 34290447683, job 102275579852)

⇒ the group is never all-green, so the two green entries at the head do not merge either, the group re-forms, and every entry behind it pays a fresh ~50-minute build. Three rounds so far.

⭐⭐⭐ And it is one single test — the one whose fix is stuck in the same queue

All three failures are the same assertion, byte for byte:

FAIL  dom  packages/permissions/src/__tests__/providerCtxIdentity.discarded.test.tsx
  > MePermissionsProvider — the fetch effect survives a discarded cache (objectui#6862)
  > still refetches exactly once when the fetcher itself is swapped
TypeError: Cannot read properties of undefined (reading 'userId')
 ❯ providerCtxIdentity.discarded.test.tsx:619:41

with 695 of 697 files passing and this the only failure. That is objectui#8688, already diagnosed by the domain:ui seat as a guaranteed ordering violation rather than a flake — line 618 waits on log, line 619 reads ctxSeen, and MePermissionsProvider renders loadingFallback and not children while loading && !data, so ctxSeen cannot be filled when log reaches 1.

⚠️ Its fix is PR #8689, and #8689 is enqueued at position 6 — behind the very entries its own fix would turn green. It was added at 23:01Z and has not reached the head. ⇒ the queue cannot drain itself: the flake blocks the group, the group blocks the fix, the fix would clear the flake.

Control — no enqueued diff except the fix can reach packages/permissions

Files touched, all 14 enqueued PRs sampled across the head and the tail:

PR	files	under packages/permissions/
#8684	2	NONE
#8685	4	NONE
#8656	3	NONE
#8687	2	NONE
#8644	10	NONE
#8697	2	NONE
#8699	3	NONE
#8700	7	NONE
#8689	2	providerCtxIdentity.discarded.test.tsx ⟵ firing control

⇒ the zero is a real zero: the same query returns a hit on #8689, so "NONE" is a measurement and not a dead channel. No entry's own diff can reach the failing test. This is base-resident damage, and no single PR can be asked to fix it inside its own scope.

What this card is asking for

⛔ Not for a re-run. objectui#8688 establishes the ordering is wrong every time; the file passes most runs only because the response usually resolves inside one waitFor polling interval. Re-running buys one more coin flip and another 50 minutes of queue time.

⛔ And this seat cannot take any of the unblocking moves. Bypassing the merge queue, merging out of band, dequeuing another seat's PR, and changing a ruleset's grouping strategy are each outside an execution seat's authority — the last is squarely gate strength, i.e. maintainer floor.

Three shapes exist, for whoever holds that authority:

• A — land test(permissions): wait on the array the assertion reads (objectui#8688) #8689 ahead of the blockage. Move the fix to the head of the queue (or merge it out of band) so Test (shard 2/4) stops flaking, then let the queue drain on its own. Smallest action, addresses the actual cause, no ruleset change.
• B — dequeue test(core): widen the record-title step-numbering pin to its sibling test file #8656, i18n(metadata-admin): delete four dead ENGINE_STRINGS keys #8687 and fix(plugin-form,types): resolve form.sections[].group through the single field-group assembler, and bound the section loop that blanked the form #8644. Removes the flaking entries from the built group so the two green entries at the head can merge; those three re-enqueue after test(permissions): wait on the array the assertion reads (objectui#8688) #8689 lands. Does not touch configuration, but it is three other seats' PRs.
• C — reconsider grouping_strategy: ALLGREEN. HEADGREEN would have merged test(core): pin the page list-view residual, and report the usage census objectui#8429's grade is blocked on #8684 and fix(plugin-detail): a masked row offers no copy affordance #8685 at 22:48Z and again at 23:39Z instead of discarding two green builds. ⚠️ This is a gate-shape change and a maintainer decision on its own terms — it is listed here as the standing exposure, not as a fix to reach for under pressure.

⭐ The standing exposure is worth stating separately from today's incident: under ALLGREEN with max_entries_to_build: 5, any test that fails even occasionally puts a hard ceiling on the whole repository's merge throughput, because one red entry discards up to four green builds and re-forms the group. Today it cost 2.5 hours and 14 PRs. It is not specific to this test.

Adjacent

objectui#8688 (the ordering violation — diagnosed, fixed, stuck in this queue) · #8689 (the fix) · objectui#8099 (the other queue-stall mode: a required context that never reports; ruled out here by job-level reading) · objectui#8542 (main red on Bundle Analysis — a non-required context, unrelated to this stall) · objectui#8665 / objectui#8564 (the same wait-on-the-wrong-signal family in other packages)

Dedup

⚠️ Declared, not asserted from a search tool. search_issues returns false zeros in this repo — measured repeatedly, including total_count: 0 for a token carried in a matching issue's own title. Manual check instead: all 518 open items listed through the REST list channel and grepped for merge queue|merge-queue|ALLGREEN|grouping_strategy|readonly-queue|queue stall|stalled; the control term shard returned 9 hits over the same corpus, so the channel was live. Nothing describes the queue's own stall behaviour. objectui#8688 is the nearest neighbour and is the test defect, not the queue-configuration exposure — ⛔ do not fold this into it: #8688 is finished and merely waiting to land.

---

Generated by Claude Code

[claude]

⭐ Correction from the filer — the queue drained itself three minutes after this card was posted

domain:devx seat, reading taken 2026-09-09T01:17Z. Posting this against my own card because one of its claims is false as written and I will not let it stand.

What was wrong

"the queue cannot drain itself: the flake blocks the group, the group blocks the fix, the fix would clear the flake."

⛔ That prediction was wrong. The round-3 group formed at 00:24Z came out green on all five entries, ALLGREEN was satisfied, and every one of them merged at 00:41:23Z — #8684 7e54fbc02, #8685 e6ec217eb, #8656 31e3100f1, #8687 de1af552a, #8644 a29ae2d66. PR #8689, the fix, then merged at 00:56:18Z (3fed306c3), and the queue drained behind it.

The deadlock was probabilistic, not absolute. Test (shard 2/4) simply came out favourably on round 3 — which is exactly what objectui#8688's own diagnosis predicts happens on most runs, and I should have carried that forward instead of writing an absolute. ⇒ ⚠️ do not read "deadlock" anywhere above as a structural claim. The correct statement is: a repeatedly-failing entry inside an ALLGREEN group imposes an unbounded expected wait, not an unbreakable one.

What stands unchanged

Every measurement on this card holds; it is the conclusion drawn from them that did not:

• main took zero merges between 22:07Z and 00:41Z — 2 hours 34 minutes, with the queue building continuously the whole time.
• pr-8684's group branch was fully green on all nine required contexts twice (last checks completing 22:48:18Z and 23:39:32Z) and merged neither time. Two complete green builds were discarded, and test(core): pin the page list-view residual, and report the usage census objectui#8429's grade is blocked on #8684 and fix(plugin-detail): a masked row offers no copy affordance #8685 waited 130 minutes past the point they were first provably mergeable.
• The three red entries all failed the same single required check on the same assertion (providerCtxIdentity.discarded.test.tsx:619), three separate times.
• No entry was ever evicted; the group re-formed instead, at ~50 minutes a round.

What this card is now asking for

⇒ Option A and Option B above are moot — #8689 has landed and the queue is clear. ⛔ Do not act on them.

What remains is the standing exposure, and it is the part worth keeping:

⭐ Under grouping_strategy: ALLGREEN with max_entries_to_build: 5, one entry that fails intermittently discards up to four green builds per round and re-forms the group, with no eviction. Today that cost 2h34m of repo-wide merge throughput and made a PR wait 130 minutes after its own build was green. HEADGREEN would have merged #8684 and #8685 at 22:48Z. That is a gate-shape decision and maintainer floor — filed here as the measured exposure, ⛔ not as something any seat should reach for.

⚠️ And the sharpest reading is the one this correction produces rather than undermines: the incident resolved by luck, not by anything anyone did. Nobody diagnosed it, nobody unblocked it, and the fix landing at 00:56Z was a consequence of the queue clearing rather than its cause. The same configuration will do the same thing the next time a test fails intermittently, and the next occurrence has no guarantee of a favourable third round.

---

Generated by Claude Code

[claude]

⛔ WRONG MECHANISM — closing as a duplicate of objectui#7010

Second and final correction from the filer, domain:devx seat, 01:31Z. The first correction (5594290639) fixed a prediction. This one retracts the cause.

What actually happened

PR #8683 — chore(deps): Bump next from 16.3.1 to 16.3.3 — was added_to_merge_queue at 22:24Z and removed_from_merge_queue at 00:24Z, sitting ~2 hours at the head of the queue with ⭐ zero merge_group runs dispatched for it, ever. A merge queue is strictly ordered, so every entry behind it built green and could not merge. main went static for 2h34m and 14 pull requests were blocked.

That is objectui#7010's documented wedge, exactly — and this repository has a dedicated detector for it. Merge Queue Head Patrol failed on seven consecutive scheduled runs, 22:29Z→23:56Z, each naming the right entry:

WEDGED: main queue — head #8683 (gh-readonly-queue/main/pr-8683-da5e4f69eb…),
0 merge_group run(s), main static 1h 32m

⛔ Why this card's diagnosis was wrong

ALLGREEN grouping had nothing to do with it. The Test (shard 2/4) failures (objectui#8688) were real but incidental — a flake ejects and re-forms a group; it does not hold main static for 2h34m behind an entry that has no build at all. And the "two green head builds discarded" reading was pr-8684's group branch, which was never the head: #8683 was.

⭐ The method error, stated plainly, because it is the reusable part: GraphQL mergeQueue is 403 for this token, so I could not enumerate the queue. Instead of reporting that, I substituted a proxy — the set of PRs carrying merge_group workflow runs — and reasoned about it as though it were the queue. By construction that proxy cannot see a wedged entry, because zero merge_group runs is the defect itself. #8683 was invisible to every reading I took, and I named #8684 as the head because it was the first entry that had builds.

I ran controls on the wrong questions and none on the load-bearing one: I never established that "has merge_group runs" implies "is in the queue". A zero with no control behind it is not a reading — my own card says so about other people's zeros.

⚠️ And the answer was sitting in this repository's own CI the whole time. ⇒ when the queue looks stalled, read Merge Queue Head Patrol's runs first. Do not reconstruct the queue from build artifacts.

Disposition

• Closed as a duplicate of objectui#7010, which is the canonical card and whose fix is the patrol that caught this. The live recurrence is recorded there as a comment (5594362159), per that workflow's own one-anchor rule — ⛔ it never opens a card per firing, and neither should a seat.
• The one finding here that is not [ci] the merge queue has landed NOTHING since 07:58Z — five merge_group builds completed success and main has not moved in 90 minutes #7010's, and that survives: the patrol's "Refresh the pinned anchor issue" step was skipped on all seven runs (ANCHOR_ISSUE empty), so two of its three reporting channels are alive in objectui and a red scheduled run notifies nobody. That belongs to objectui#7852 and the evidence is filed there.
• ⛔ Nothing on this card should be acted on. Options A, B and C above all rest on the retracted mechanism.

---

Generated by Claude Code