[ci] the merge queue has landed NOTHING since 07:58Z — five merge_group builds completed `success` and `main` has not moved in 90 minutes

[zhuangjianguo]

Filed by the domain:devx @ objectui execution seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk, R36. Filed unassigned; ⛔ routing, domain:*, type and grading are the triage seat's.

⚠️ This is live right now and it is repo-wide, not one lane's. At least three pull requests across at least two lanes are held.

Measured

main last advanced at 2026-08-31 07:58:08 +0000 (a5a799d63). Read at 09:26Z after git fetch origin main — 88 minutes with zero commits.

In that same window, ci.yml produced five merge_group runs that all completed success:

queue ref	created	finished	conclusion	landed?
pr-6995-c704188d…	08:20:27	08:33:27	success	⛔ no
pr-6999-80610f0d…	08:34:01	08:46:53	success	⛔ no
pr-7002-b211024c…	09:02:02	09:15:04	success	⛔ no
pr-6995-f0017ee7…	09:11:24	09:24:08	success	⛔ no
pr-6999-c993a682…	09:11:25	09:24:40	success	⛔ no

The three batched groups immediately before the stall (pr-6979, pr-6971, pr-6983, all created 07:58:1x) built green and all three landed. So the queue was working, and stopped.

⭐ Note the shape: #6995 and #6999 have each been built twice. They were enqueued, built green, silently did not merge, and were re-queued.

Affected

• fix(devx): add a property-chain leg to check-i18n-dead-keys #6995 (issue finding(i18n): check-i18n-dead-keys reports LIVE keys as CONFIRMED when a consumer reads the pack by property access #6666) and feat(scripts): guard a package's published contract fields, not only its source #6999 (issue check-changeset-presence.mjs guards only <pkg>/src/**, so a published-contract change in package.json is owed no changeset — live instance in #6683 #6736) — this seat's, both mergeable_state: clean, both ACCEPTed, neither ejected and neither carrying a merge-queue triage comment.
• fix(fields): NumberField reads the published error slot #7002 — not this seat's. Named so the owning lane knows its PR is not stuck on anything it did.

⛔ No PR involved is red. No ejection notice was delivered for any of them.

The repo's own documentation names this failure shape

.github/workflows/governed-surface-guard.yml, on its merge_group leg:

a requirable context that does not report on a queue build stalls the queue until the ruleset's 60-minute status-check timeout

⭐ And the timing fits: #6995's two builds are 51 minutes apart (08:20 → 09:11), which is what a ~60-minute status-check timeout followed by a re-queue would look like.

⛔ One hypothesis tested and FALSIFIED — do not re-derive it

The obvious candidate is "a required context comes from a workflow with no merge_group leg, so it never reports on a queue build." It is not that. Measured:

• Twelve workflows have a pull_request leg and no merge_group leg: changeset-guard, check-links, cross-repo-issue-closer, dependabot-auto-merge, half-state-patrol, hook-selftests, labeler, live-e2e, node-esm-load-gate, performance-budget, published-dist-gate, spec-range-floors.
• All 22 names in REQUIRED_CONTEXTS (scripts/dependabot-merge-gate.mjs) are produced by workflows that do carry a merge_group leg.
• Intersection: empty.

⚠️ Bound on that reading, stated: REQUIRED_CONTEXTS is this repository's own declaration. The live ruleset's required-check set is a repository setting an agent seat cannot read, so a context required there but absent from that list would not be visible to this measurement. That gap is exactly where the remaining explanation could live.

What is needed, and from whom

⛔ Not resolvable by any agent seat. It needs someone who can read the branch ruleset for main and answer one question: which checks does the live ruleset require on a queue build, and is every one of them reporting on merge_group refs?

Two adjacent things worth checking at the same time:

1. Whether a GitHub incident is in play — the symptom (green builds, no merge) is consistent with one, and that would make the ruleset clean.
2. Whether the queue's own merge step is failing for a permissions reason, which would also produce green builds and no commits.

⛔ Deliberately not done

• ⛔ No PR was dequeued, re-queued by hand, or merged outside the queue. Queue-external merges are forbidden here, and re-queueing by hand would add churn to a queue that is already cycling PRs through timeouts.
• ⛔ No empty commit to "kick" anything.

Related

#6588 (closed 08-26) — nearest prior instance, "merge-queue groups are stalling: 9 workflow runs stuck in queued". ⚠️ Different symptom: there the runs never finished; here they finish green and still nothing merges. #4986 (closed 08-24) — the era when the queue produced zero merge_group builds; ⛔ that premise is long dead, the queue has 530 historical merge_group runs of ci.yml.

[zhuangjianguo]

Update 09:45Z — still stalled at 107 minutes, and the population has grown to six pull requests

domain:devx @ objectui seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk. Re-measured, ⛔ not re-asserted.

main remains a5a799d63, 2026-08-31 07:58:08 +0000. Two more merge_group runs have completed success since the table above, and two more are in flight:

queue ref	created	finished	conclusion	landed?
pr-7002-ac237dae…	09:24:24	09:37:14	success	⛔ no
pr-7005-46f91824…	09:24:47	09:38:01	success	⛔ no
pr-7001-538b8c74…	09:37:30	—	in progress	—
pr-7009-aaff014e…	09:38:05	—	in progress	—

⇒ Seven successful merge_group builds since 07:58 and zero commits on main. The affected set is now #6995, #6999, #7001, #7002, #7005, #7009 — six pull requests across several lanes, only three of them this seat's.

⭐ #7002 has now been built twice (09:02→09:15, 09:24→09:37), both green, neither landing. That is the same two-cycle shape #6995 and #6999 showed, on a PR this seat has nothing to do with — so the cycling is a property of the queue, ⛔ not of any one PR or lane.

⚠️ A reading I could not take, stated as not taken

#6995 and #6999 are absent from the four most recent queue builds, having last built at 09:11. Both are still open, draft: false, mergeable_state: clean, with no merge-queue triage comment and no ejection notice on either.

That is consistent with two different stories — still queued but behind the newer entries, or silently dequeued after a second timeout — and ⛔ I cannot distinguish them: queue membership is not readable through the tooling available to an agent seat here, and updated_at on both has been frozen at their enqueue time since 08:20. Recording it as undetermined rather than guessing, because the two stories imply different remedies.

⛔ Still deliberately not done

No hand re-queue, no dequeue, no queue-external merge, no empty commit. Re-queueing by hand would reorder a queue that other lanes are also waiting in, and would add churn to a mechanism that is already cycling entries through timeouts — ⛔ without addressing whatever is preventing the merge step itself.

The ask in the card body is unchanged and is still the only thing that moves this: someone who can read main's branch ruleset, confirming which checks it requires on a queue build and whether each reports on merge_group refs.

---

Generated by Claude Code

[zhuangjianguo]

Update 10:23Z — 145 minutes. Nine green queue builds, zero commits. And the open question above is now answered.

domain:devx @ objectui seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk. Re-measured.

main still a5a799d63 / 07:58:08 +0000.

queue ref	created	conclusion
pr-7001-538b8c74…	09:37:30	success ⛔ not landed
pr-7009-aaff014e…	09:38:05	success ⛔ not landed
pr-6995-dd117f2e…	10:14:26	in progress
pr-6999-09a8d794…	10:14:26	in progress
pr-7002-52fb381c…	10:14:27	in progress

⇒ Nine merge_group runs have completed success since 07:58 and main has not moved once.

⭐ Resolving the reading I recorded as undetermined

My 09:45Z update said #6995 and #6999 were absent from recent queue builds and that I could not distinguish "still queued, behind newer entries" from "silently dequeued".

Answered: they were never dequeued. Both are building again at 10:14 — a third cycle each. So the queue is holding its entries and re-forming groups around them; ⛔ nothing is being ejected, and the absence of an ejection notice was accurate rather than a missed delivery.

⭐ That narrows the failure: it is not entry loss and not a check failure. Groups form, build green, and the merge step itself never happens — then the group is rebuilt from scratch. #7002 is now on its third cycle too, on a PR from a different lane.

Cost so far

Nine full CI runs of ci.yml — each ~13 minutes across ~27 jobs — spent on merges that did not occur, plus three more in flight. That is the concrete price of leaving this until someone can read the ruleset.

⛔ Unchanged: no hand re-queue, no dequeue, no queue-external merge, no empty commit. The ask in the card body is unchanged and is still the only thing that moves this.

---

Generated by Claude Code

[zhuangjianguo]

⭐ The ruleset's required-check list is ELIMINATED as the cause — measured against the maintainer's own reading

domain:devx @ objectui seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk, 11:45Z. main still a5a799d63 / 07:58:08Z — 227 minutes.

The maintainer supplied the live ruleset's required status checks — the one reading no agent seat could take. Nine names:

Lint · Type Check · Build & E2E · Test (shard 1/4) · Test (shard 2/4)
Test (shard 3/4) · Test (shard 4/4) · Build Docs · Changeset Declaration

Diffed against what actually runs on merge_group refs — the gap is EMPTY

required check	producing workflow	merge_group runs	recent queue builds
Type Check · Build & E2E · Test shards 1–4 · Build Docs	ci.yml	530	success
Lint	lint.yml	545	success
Changeset Declaration	changeset-presence.yml	545	success

Newest, on the current cycle — every one completed/success:

11:30:40 pr-7009 11:30:09 pr-7001 11:17:42 pr-7005
11:17:42 pr-7002 11:17:41 pr-6999 11:17:38 pr-6995

⇒ All nine required checks report on queue builds, and all nine pass. ⛔ The "a requirable context that does not report on a queue build" mechanism — the one this repo's own guard docblock names, and the one I chased first — is not what is happening here.

Two further hypotheses also dead

• ⛔ Not a workflow change in the last landed batch. The 07:58 batch (a5a799d63, b3d562c02, 348724ea1) and the 07:29–07:31 batch before it touch zero files under .github/workflows/. Nothing about the queue's configuration changed at the moment it stopped.
• ⛔ Not entry loss or ejection. fix(devx): add a property-chain leg to check-i18n-dead-keys #6995, feat(scripts): guard a package's published contract fields, not only its source #6999, fix(fields): NumberField reads the published error slot #7002 are now on a fourth cycle.

What that leaves — all of it above an agent seat's access

Checks are green and complete, so the failure is downstream of the status-check gate, in the merge step itself. Candidates, none testable from here:

1. A non-status-check ruleset condition — required approving reviews, required signed commits, required linear history (incompatible with the queue's merge method), or a push restriction the queue's merge actor cannot satisfy.
2. Merge-queue settings proper, rather than branch-protection ones.
3. A GitHub platform incident — "builds green, merge never happens, group rebuilt" is a plausible shape for one, and it would leave every repository setting clean.

⭐ The one read most likely to just say the answer

The merge queue's own page — /queue/main on this repository — lists the current entries and, per entry, the reason one is not merging. Everything above is inference from run history; that page reports it directly.

⛔ Unchanged: no hand re-queue, no dequeue, no queue-external merge, no empty commit. All three of this seat's PRs have auto-merge armed and land by themselves once the queue recovers.

---

Generated by Claude Code

[zhuangjianguo]

✅ RESOLVED — the blocker was PR #6994, a Dependabot entry stuck at the head of the queue

domain:devx @ objectui seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk, 12:01Z. The maintainer removed #6994 from the merge queue at ~11:47Z, and the queue drained.

main HEAD: 2878cede4 fix(devx): add a property-chain leg to check-i18n-dead-keys (#6995)

⇒ First commit on main since 07:58:08. The stall ran ~4 hours.

The mechanism, with the timing that identifies it

time	event
07:58:08	last successful landing — the queue was healthy
08:02:08	#6994 opened (Dependabot, streamdown 2.5.0 → 2.6.0)
08:15:33	its dependabot merge-gate job completes success; its updated_at freezes at 08:15:29 — it enters the queue
08:20:27	first merge_group build that goes green and does not land
08:20 → 11:47	every entry behind it cycles: build green → no merge → group rebuilt
~11:47	#6994 removed from the queue
12:00	#6995 merges

⭐ A head-of-queue entry that cannot merge blocks everything behind it, and that single fact explains every observation this card recorded: nothing was ejected (they were queued, correctly), every build was green (speculative builds should pass), no check ever failed, and the group kept re-forming.

⛔ #6994's own checks were not the tell. All 28 completed — 9 of 9 required checks green on its PR leg. It was green and still unmergeable, which is why the status-check angle led nowhere.

What was eliminated along the way — ⛔ do not re-derive any of these

1. A required context with no merge_group leg. All 22 declared REQUIRED_CONTEXTS come from workflows that have one.
2. The live ruleset's required-check list. The maintainer supplied it (9 names); every one runs on merge_group and passes — ci.yml 530 runs, lint.yml 545, changeset-presence.yml 545.
3. A workflow change in the last landed batch. Both batches before the stall touch zero files under .github/workflows/.
4. Entry loss / ejection. Entries reached a fourth cycle, still queued.

⚠️ The remaining GitHub-internal reason #6994 could not merge is not established here — the Dependabot identity interacting with a push restriction is the most likely class, but it was not measured and should not be recorded as fact.

⭐ Worth a follow-up: this repo has now been blocked by this class twice

objectui#4973 records the prior instance — "dependabot-auto-merge … 今日全仓阻断(#4968)的真正成因". Same family: a Dependabot PR plus auto-merge, blocking the whole repository.

⚠️ Also relevant: dependabot-auto-merge.yml is one of the twelve workflows in this repo with no merge_group leg. Whether that is connected is unmeasured — but "a Dependabot PR can enter the queue and wedge it" is now a twice-observed shape, and it currently has nothing watching for it. ⛔ Filing that is triage's call, not this seat's; recorded here so the second instance is not forgotten like the first.

Affected PRs — now unblocked

#6995 merged. #6999, #7001 (this seat's) and #7002, #7005, #7009 (other lanes') should follow as the queue drains.

---

Generated by Claude Code

[zhuangjianguo]

⚠️ RECURRED — third occurrence today, live now. And this time the head entry is readable from an agent seat.

domain:devx @ objectui seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk, 13:12Z. I marked this card RESOLVED at 12:01Z. It recurred at 12:19Z, eighteen minutes later, with a different Dependabot PR at the head.

main: b458300ca — last advanced ~12:14Z, 58 minutes ago
head of queue: pr-6988-b458300ca… formed 12:19:37Z — 52 minutes old

The live queue — a seven-deep chain, three of them fully green and stuck

pos	entry	builds on	merge_group runs
1	pr-6988 (Dependabot, react group)	b458300ca = main	⛔ ZERO — of any workflow
2	pr-7012	599ded278	15/15 success
3	pr-7000	a8bb0cf6b	15/15 success
4	pr-7013	1a2b32dbf	15/15 success
5	pr-7017	019782846	in progress
6	pr-7018	4e64a9806	in progress
7	pr-7019	4ede8b062	in progress

⭐ The signature — a two-call check that replaces the four-hour investigation above

This card burned ~4 hours and needed a reading only the maintainer could take. It did not have to. The whole of it collapses to one measurement I never took this morning: the runs on the head entry's own queue ref.

Every reading in this card's history was taken on the entries behind the blocker — which is exactly why everything looked green and nothing explained itself. Speculative builds behind a wedged head should pass. They are not the subject.

list_workflow_runs(event=merge_group,
 branch=gh-readonly-queue/main/pr-<head>-<basesha>)

• head pr-6988 → total_count: 0, 52 minutes after the entry was formed.
• control pr-7013 → total_count: 15, all success, every run created_at within the same second as the entry's formation.

⭐ Runs appear instantly on entry formation. Zero runs at 52 minutes is not slowness; it is absence.

What the absence rules out, mechanically

All fifteen workflows produced zero runs. A workflow-level if: still creates a run and marks it skipped — so this is not a condition inside any workflow. The merge_group event was never dispatched for this entry at all. That is upstream of every check, which is why no check ever failed and why the status-check angle led nowhere for four hours.

⛔ One tempting hypothesis, FALSIFIED — do not re-derive it

"Dependabot queue entries never get merge_group runs." False as a universal. Dependabot PRs have merged through this queue: 1a4381083 (#5962, 2026-08-25). The failure is conditional, not categorical.

⚠️ But the conditional has teeth: no Dependabot PR has merged in six days. Zero in the 200-commit window spanning 2026-08-26 → 2026-08-31; the last is 08-25. Something changed on or about 08-26.

Three-for-three on the identity

#	blocker	opened	outcome
objectui#4968 / #4973	Dependabot + auto-merge	08-17	repo-wide block
#6994 (streamdown bump)	Dependabot	08:02Z today	4h block, cleared by removal
#6988 (react group)	Dependabot	07:57Z today	live now

⛔ Still not established: why GitHub declines to dispatch merge_group for these entries. Not measured, so not asserted. But the detection is now cheap and belongs in automation — dependabot-auto-merge.yml remains one of the twelve workflows with no merge_group leg, and nothing watches for a head entry sitting checkless.

The action

Same as at 11:47Z: remove #6988 from the merge queue. ⛔ Not available to this seat — the tooling here exposes no dequeue, and #6988 is another lane's PR. Everything behind it lands on its own once the head clears.

⛔ Unchanged and deliberate: no hand re-queue, no queue-external merge, no empty commit.

---

Generated by Claude Code

[zhuangjianguo]

✅ Cleared — #6988 was removed, and the new head is healthy on the same measurement

domain:devx @ objectui seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk, 13:23Z. Recurrence lasted ~64 minutes (12:19 → ~13:20).

The queue re-formed from scratch on a fresh chain rooted at live main:

pr-7012 on b458300ca (= main) → pr-7000 → pr-7013 → pr-7017 → pr-7018

⭐ The same two-call diagnostic, now run on the new head, returns the opposite answer — which is what makes it a usable instrument rather than a one-off observation:

head entry	formed	merge_group runs
pr-6988 (removed)	12:19:37	0 after 58 minutes
pr-7012 (current)	13:20:38	15, created 13:20:38 — same second

11 of the 15 already success. Both directions measured, so the check discriminates rather than merely agreeing with the outcome.

What this card is now good for

Three occurrences today, all cleared the same way, all diagnosable in two calls. The detection is cheap and mechanical; nothing currently watches for it. ⛔ Whether that becomes a patrol is triage's call — but the signature is now written down twice with both a positive and a negative reading, so the next occurrence should cost minutes, not hours.

⛔ Unchanged and deliberate throughout: no hand re-queue, no dequeue by this seat, no queue-external merge, no empty commit.

---

Generated by Claude Code