Repository navigation
Queue-flake anchor: scripts/dropped-refinements.test.ts #29530
Description
scripts/dropped-refinements.test.ts has ejected 10 pull requests from the merge
queue within a rolling 24 hours — 1 independent hit 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 |
|---|---|---|
| #29437 | S1 · root | 41495583355 · 41491875177 · 41491559206 |
| #29454 | S1 · inherited | 41495598866 · 41494560578 |
| #29464 | S1 · inherited | 41498966913 |
| #29495 | S1 · inherited | 41498375728 · 41495260722 |
| #29505 | S1 · inherited | 41495587695 · 41491992528 |
| #29511 | S1 · inherited | 41495591770 · 41493209726 |
| #29514 | S1 · inherited | 41495594461 · 41494474291 |
| #29515 | S1 · inherited | 41498313013 · 41495019103 |
| #29519 | S1 · inherited | 41499208591 |
| #29525 | S1 · inherited | 41498916863 |
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 chain reaches another victim's queue HEAD (directly, or through
green groups queued between them) 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 root 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.
A later queue build that went green on the same main is a control only if its
affected-only selection ran the failing package; a green group that never selected
it carried the same tree without testing it.
Last refreshed by queue build 41498966913 (PR #29464).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
objectstack-fleet commentedon Nov 2, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: p1 ·
domain:spec·pm:queue· not a flake · 2026-11-02T18:15Z⛔ Not a claim.
dropped-refinementsledger's header total reads 998 against a body of 993. This is the same class as Queue-flake anchor: scripts/strictness-ledger-doc.test.ts #29524, a generated ledger regenerated by two queued PRs against different bases. The root is feat(spec): a record page can name the apps whose routes open it (PageSchema.apps) #29437; fix(pm): the relay reads no runner 403 as the egress proxy's, and a refused advisory row names its cause #29505, docs(spec): the disabledActions description names Setup › Packaged Actions, not the retired Packaged automation page #29511 and feat(pm): a ruled decision card still in the box is a patrol row, and the director's ruling lands with its knock #29515 were inherited. The queue has been green since 17:54Z. feat(spec): a record page can name the apps whose routes open it (PageSchema.apps) #29437 mergesorigin/mainand regenerates before re-entering, serially (§D). p1.Generated by Claude Code
objectstack-fleet commentedon Nov 2, 2026
domain:spec#5 · os-warren · session_01JQwxbWR3K3h7i1ytwycVg1
Closing: the cause is fixed and the queue has been green since · 2026-11-02T23:27Z
Path: none (the seat closes the anchor; no card thread, no PR)
dropped-refinementsledger against different bases, so the merged tree's header read 998 against a body of 993origin/mainand regenerating before it re-entered the queue (landing-operations.md§D)merge_groupCI runs created after 2026-11-02T18:45Z concludedsuccess(one was still running at read time)Closing as
completed, with the fix named above. The class can come back whenever two PRs that regenerate the same counts ledger share one queue window. The remedy stays the §D serial relay, and the workflow reopens the conversation on the next ejection.pm:queueis removed in the same step;domain:specandpriority:p1stay.