Repository navigation
Description
test/run-dev-unbuilt-workspace.e2e.test.ts has ejected 16 pull requests from the merge
queue within a rolling 24 hours — 10 independent hits once
GitHub's speculative stacking is accounted for. This issue is the single place for
that conversation; it is refreshed by the merge-queue-triage workflow on every
further ejection.
| PR | stack | queue build |
|---|---|---|
| #14499 | independent | 33663028874 |
| #14528 | S2 · root | 33695020929 · 33689105623 · 33674211749 |
| #14629 | independent | 33660420831 |
| #14631 | independent | 33668324620 |
| #14649 | independent | 33671786568 |
| #14651 | independent | 33678366780 |
| #14665 | independent | 33671791799 · 33669892536 |
| #14675 | S2 · inherited | 33674214419 · 33670772221 |
| #14687 | independent | 33676145614 |
| #14692 | independent | 33678836122 |
| #14715 | S2 · inherited | 33696599687 · 33695022067 · 33685006566 · 33682230163 |
| #14733 | S2 · inherited | 33696601161 · 33695084575 |
| #14735 | S2 · inherited | 33697809557 · 33695118192 |
| #14736 | S2 · inherited | 33697811481 · 33696603273 |
| #14739 | S2 · inherited | 33696604625 |
| #14741 | independent | 33699706473 |
stack column is read out of the queue
branch names: GitHub builds each queued PR on top of the previous entry, so a
build whose BASE commit IS another victim's queue HEAD contains that victim's
tree by construction. A single deterministic break therefore ejects every PR
behind it, and the raw victim count climbs with QUEUE DEPTH until the owner
lands a fix. Start with the roots above; an inherited row is a bystander until shown otherwise.
This issue is a NAME, not a diagnosis. The workflow that files it reads the
failing test file path out of the job logs and counts PRs; it does not
know whether this is a flake, a load/timing cliff, a semantic conflict between
queued PRs, or a real regression, and it does not act on any of those. No test is
skipped, quarantined or re-queued by it, and no PR is labelled by it — weakening
a gate stays a human act.
What to do with it: read one victim PR's triage comment for the failure REASON
line beside the FAIL line (a timeout and an assertion are the same FAIL line and
opposite diagnoses), decide the cause, and close this issue with the fix or with
the reason it is not one.
Last refreshed by queue build 33699706473 (PR #14741).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
huangyiirene commentedon Sep 3, 2026
Triage — duplicate of #14648. Seventh anchor filed for
test/run-dev-unbuilt-workspace.e2e.test.ts(after #14679, #14702, #14706, #14720, #14727). Closing as duplicate; #14648 remains the surviving anchor, ispm:dispatchedwith PR #14715 open against it.⭐ This one is not merely another duplicate — it is the specimen that yielded the root cause of the aggregation defect, now recorded on #14682:
merge-queue-triage.yml:552setsconst ANCHOR_LABEL = 'finding', and the anchor lookup at:624-626islistForRepo({ state: 'open', labels: ANCHOR_LABEL }). The identity match inside it (body marker or exact title,:632-633) is sound — but it only runs over issues that still carryfinding.findingmeans awaiting first grading, so the first seat to triage an anchor removes it and the anchor leaves the searchable set while still open.⇒ #14648 is open, byte-identical in title, same author, and matches the identity predicate — and was passed over anyway, because grading had taken
findingoff it. That is why this card exists and why the count restarted at a recomputed 16-PR window (with #14629 appearing in both bodies) instead of #14648's 3 being extended.⛔ Not re-adding
findingto #14648 to break the loop: that would make a graded, dispatched card misstate its own state to work around a workflow bug. The fix belongs in #14682.stackcolumn's own warning applies — start from theindependentrows.Generated by Claude Code