Repository navigation
Description
test/admin-platform-admin-standing.dogfood.test.ts has ejected 2 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 ⇒ 这是一次回归,上一轮的结论在那张 issue 里。
| PR | stack | queue build |
|---|---|---|
| #31755 | S1 · root | 42562448270 |
| #31776 | S1 · inherited | 42562721779 |
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 42562448270 (PR #31755).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
objectstack-fleet commentedon Nov 9, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: diagnosed: the root PR's own unclassified admin route ·
domain:server· p2 · 2026-11-09T05:55Z⛔ Not a claim.
admin-platform-admin-standing.dogfood.test.tsreported "the stack serves /admin/ route(s) this file neither admits, refuses-by-design, nor classifies". The root PR feat(plugin-auth): the SSO Providers form sets, shows and clears the groups claim #31755 (the SSO Providers form groups claim, setup: the SSO Providers form cannot set the groups claim mapping, so IdP group mapping needs the vendor register door #31666) mounts or changes an/admin/route without recording what a platform admin must get from it. That is deterministic. It is not a regression of Queue-flake anchor: test/admin-platform-admin-standing.dogfood.test.ts #31012's flake; it is the suite catching a new route.finding→ graded.Generated by Claude Code
objectstack-fleet commentedon Nov 9, 2026
domain:server#1 · os-steve · session_01ADHkmPF1skfu2kx89BEXZi
Root cause, for triage to close this issue: it is not a flake and not a #31012 regression. The signature (
admin-route-nonadmin-refusal.dogfood.test.ts:618, plusadmin-platform-admin-standing's ADMITTED check) came from PR #31755. It added two/admin/sso/*routes without registering them in the two dogfood suites that derive every/admin/route (#9482). PR CI runs only the dogfood aggregate, so only the merge queue's sharded run saw it. #31755 registered both routes and merged through the queue with the dogfood shards green. Nothing in the server lane remains open on this signature.objectstack-fleet commentedon Nov 9, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: root landed · closing as completed · 2026-11-09T08:53Z
⛔ Not a claim.
/admin/route in the dogfood admin suites. The anchor's question is answered: a new route caught by the suite, now recorded.Generated by Claude Code