The merge queue has landed nothing for 2h37m while continuously occupied — chains form, churn, and are dumped without `main` advancing

[os-warren]

Filed unassigned by the domain:ui execution seat (session session_012wwHa4aaFybxXrfmfHioDM) while tracking PR #7090 to MERGED. Grading and domain:* are triage's.

⛔ No root cause asserted. Everything below is a reading; the diagnosis is not mine and I have not guessed at it.

The measurement

reading	value
refs/heads/main	592acafb, unmoved across five reads between 17:53Z and 18:18Z
main's last commit time (--first-parent)	2026-08-31T15:41:56Z
time of the last reading	2026-08-31T18:18:39Z
⇒ elapsed with no merge	2h 37m
merge queue during that window	continuously occupied, never empty

This is not an idle queue. A drained queue and a stuck one look identical if you only read "is anything queued" — so the discriminator is that the queue held entries at every single read while main never advanced.

What the queue did in that window

Read from refs/heads/gh-readonly-queue/main/* with refs/heads/main as an in-query control every time (it resolved on every read), and with the explicit URL form, since git ls-remote origin from a non-repo cwd returns empty with exit 0.

17:53Z — chain of six:
pr-7074 → pr-7084 → pr-7076 → pr-7078 → pr-7085 → pr-7090

~18:00Z — all six gone, a different five, keyed from the same unmoved main:
pr-7056 pr-7057 pr-7059 pr-7062 pr-7065

18:18Z — eight, with two of the dumped entries back:
pr-7056 pr-7057 pr-7059 pr-7061 pr-7062 pr-7065 pr-7074 pr-7084

⇒ Entries are being dumped and re-admitted while nothing merges. The first chain's six left the queue with main unmoved, so none of them landed.

What is NOT the explanation

• ⛔ Not runner starvation. The 30 most recent merge_group workflow runs at 17:54Z were all success (pr-7057, pr-7062, pr-7065), completing in seconds. Jobs are being scheduled and are passing. This is the discriminator against the previously-recorded starvation incident, where the symptom was jobs queued for a runner.
• ⛔ Not one bad PR. Six entries from two different seats were dumped together. fix(plugin-grid): gate the server $select projection on field-level security #7090's own 30 checks are 27 success / 3 skipped / 0 failure, mergeable_state: clean, and no merge_group run ever ran for pr-7090 — it was never tested, so it cannot have failed one.
• ⛔ Not the 5-entry cap. I believed that at 18:03Z from three consecutive reads showing exactly five. The 18:18Z read shows eight, which falsifies it. Recording the correction rather than leaving the wrong number in circulation.

Why this is worth a card rather than waiting it out

Every lane lands through this one queue, so a queue that accepts entries and merges none is shared damage, not one seat's problem. At the time of filing it is holding work from at least two seats: the domain:ui predecessor's #7074 / #7076 / #7078 / #7084 / #7085, this seat's #7090, and several dependabot PRs.

⚠️ It is also invisible from inside any one seat's normal loop: each PR reports green, mergeable_state: clean, and "enqueued". Nothing on a PR page says the queue has not merged anything for two and a half hours. It only shows up if you read main's own advance time — which is what "track to MERGED, not to enqueued" means in practice.

Reproduce

git ls-remote https://github.com/objectstack-ai/objectui.git 'refs/heads/gh-readonly-queue/main/*'
git ls-remote https://github.com/objectstack-ai/objectui.git refs/heads/main
git log origin/main --first-parent -1 --format='%h %cI %s'

If the first command returns entries and the third's timestamp is hours old, the condition is live.

Related

• The half-state patrol needs its anchor issue created and HALF_STATE_ANCHOR_ISSUE set — a maintainer action outside GitHub's API surface for agent seats #5986 — Half-State Patrol has no HALF_STATE_ANCHOR_ISSUE on this repo, so the hourly sweep has nowhere to land. Different defect, same shape: a protocol running with nothing reading its output.

[os-warren]

Resolved on its own — the queue recovered. Closing, with the readings that say so and one correction to the card.

domain:ui seat, session session_012wwHa4aaFybxXrfmfHioDM.

The condition is gone

reading	at filing (18:18Z)	now (23:40Z)
refs/heads/main	592acafb, frozen since 15:41:56Z	2c3cd1b, last commit 20:16:58Z
elapsed with no merge	2h 37m	—
queue refs	occupied, churning	drained (zero entries)

⇒ main advanced again at 20:16:58Z, roughly two hours after this was filed, and the queue has since drained to empty. The PR this was found under, #7090, merged — objectui#6898 is present in packages/plugin-grid/src/ObjectGrid.tsx on origin/main.

⛔ No fix was applied by anyone in this lane, so this closes as "the condition cleared", ⛔ not as "we fixed it". If it recurs, the reproduce block below still stands.

⛔ Correction to this card's own framing

I titled it "landed nothing for 2h37m while continuously occupied", and the 2h37m and the occupancy are both measured and stand. But the seat handover (#7089), written by the predecessor seat and which I had not read when I filed this, names the mechanism I was missing:

Ejection vs merge: a front merge moves main; an ejection rebuilds every entry with a new sha. Happened twice today (once freezing main ~80 minutes).

⇒ What I recorded as an unexplained "queue-wide reset" is a known and already-characterised failure mode on this repo: a front-entry ejection rebuilding every entry behind it. My window caught two of those back to back. That is a materially better explanation than the card's, and it was available on another card at the time I filed.

⚠️ Also from that handover, and it bears directly on how I read the queue here:

ref-absent is NOT evidence of not-enqueued. Propagation lag measured 29s / 31s / 29s on three occasions — and then 7.5–14 minutes on a fourth. Prefix match confirms positives only.

I treated my PR's missing ref as evidence it had left the queue. That inference was unsound, even though the surrounding facts (six entries gone, main frozen) pointed the same way. ⭐ A prefix match on the queue refs confirms a positive and nothing else.

What survives as worth keeping

The one durable point: a stuck queue is invisible from inside any single seat's loop. Every PR reports green, mergeable_state: clean, "enqueued". Nothing on a PR page says the queue has merged nothing for hours. The only reading that shows it is main's own advance time:

git log origin/main --first-parent -1 --format='%h %cI %s'

⇒ That belongs in the landing routine, not in an incident card. Recording it here rather than leaving a closed card as its only home.

Closing as completed.

---

Generated by Claude Code