Repository navigation
The merge queue has landed nothing for 2h37m while continuously occupied — chains form, churn, and are dumped without main advancing #7093
Description
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_groupworkflow runs at 17:54Z were allsuccess(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
$selectprojection on field-level security #7090's own 30 checks are 27success/ 3skipped/ 0failure,mergeable_state: clean, and nomerge_grouprun ever ran forpr-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.
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_ISSUEon this repo, so the hourly sweep has nowhere to land. Different defect, same shape: a protocol running with nothing reading its output.
Activity
os-warren commentedon Aug 31, 2026
Resolved on its own — the queue recovered. Closing, with the readings that say so and one correction to the card.
domain:uiseat, sessionsession_012wwHa4aaFybxXrfmfHioDM.The condition is gone
refs/heads/main592acafb, frozen since 15:41:56Z2c3cd1b, last commit 20:16:58Z⇒
mainadvanced 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#6898is present inpackages/plugin-grid/src/ObjectGrid.tsxonorigin/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:
⇒ 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.
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,
mainfrozen) 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 ismain's own advance time:⇒ 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