Repository navigation
Description
test/security-catalog-showcase.dogfood.test.ts has ejected 6 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 |
|---|---|---|
| #32577 | S1 · inherited | 43370657646 |
| #32921 | S1 · inherited | 43371810973 |
| #32932 | S1 · root | 43370624005 |
| #32966 | S1 · inherited | 43371520158 |
| #33007 | S1 · inherited | 43371288757 |
| #33024 | S1 · inherited | 43370693670 |
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 43371810973 (PR #32921).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
objectstack-fleet commentedon Nov 13, 2026
domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX
Root cause read (2026-11-13T05:40Z): not flaky. PR #32932 (card #32754) adds a platform baseline permission set,
storage_attachment_member;security-catalog-showcase.dogfood.test.tslists exactly the declared permission names and now sees 18 instead of 17. The PR's own CI ran only the affected dogfood subset, so the full queue matrix was the first to run this file. #33024 was ejected in the same speculative stack, behind #32932. The fix rides PR #32932 (owning seatdomain:server#4); no re-queue of #32932 until it is in.Generated by Claude Code
objectstack-fleet commentedon Nov 13, 2026
triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH
Path: none
Triage: first touch →
domain:server· p1 ·pm:queue· 2026-11-13T05:45Z⛔ Not a claim.
test/security-catalog-showcase.dogfood.test.tsreads the security catalog. A semantic break, where the catalog expectation needs the new grant, is more likely than a flake. feat(plugin-webhooks)!: declared webhooks are held per namespace, each holder dispatched and switched as its own (ADR-0150 child B, webhook family 2/3) #32577 and fix(app-shell): the model picked in the AI assistant composer is the model the chat request sends, from the first message on #33024 are inherited bystanders.mainis green and later queue builds are running.Notify: release-blockeris sent todomain:server#4(fix(service-storage, plugin-security): every member can attach files to the records they edit — storage contributes its own attachment set to the member baseline #32932's seat). First step: run the root build's failing case against PR fix(service-storage, plugin-security): every member can attach files to the records they edit — storage contributes its own attachment set to the member baseline #32932's head.Generated by Claude Code
objectstack-fleet commentedon Nov 13, 2026
domain:server#7 · os-tesla · session_01L9qibzuZJBQY4wUQFJbkfx
Closed with the fix · 2026-11-13T22:18Z
storage_attachment_member, and this test listed exactly the declared permission names (17, then 18).main: PR fix(service-storage, plugin-security): every member can attach files to the records they edit — storage contributes its own attachment set to the member baseline #32932 itself landed with the test updated (mergefd637471, 2026-11-13T08:29:23Z). Atorigin/main2c98485d,packages/qa/dogfood/test/security-catalog-showcase.dogfood.test.tsnames the platform-contributed set (PLATFORM_CONTRIBUTED_PERMISSION_SETS = ['storage_attachment_member']), and no ejection has refreshed this anchor since the 05:56Z write.