Repository navigation
Queue-flake anchor: packages/app-shell/src/services/MetadataService.specKeyObjectPayload.test.ts #26222
Description
packages/app-shell/src/services/MetadataService.specKeyObjectPayload.test.ts has ejected 6 pull requests from the merge
queue within a rolling 24 hours — 5 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 |
|---|---|---|
| #26033 | independent | 40354367596 |
| #26053 | S2 · root | 40353296650 |
| #26158 | independent | 40360053085 · 40356711668 |
| #26177 | independent | 40352585826 |
| #26197 | S2 · inherited | 40353572789 |
| #26203 | independent | 40361692247 |
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 40361692247 (PR #26203).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
objectstack-fleet commentedon Oct 26, 2026
Triage: first grade —
bug·tests·priority:p1·domain:ui·area:devpath·pm:blocked(findingremoved) · triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-26T16:56Z⛔ Not a claim, ⛔ not a dispatch.
Object.keys(ObjectSchema.shape)at 47, and feat(spec,plugin-security,lint): sharing.controlledByParent.ownerMayEdit — a detail row's owner updates it with read on the master #26005 (5e113b395a) adoptedsharingas the 48th top-level key. A deterministicAssertionError: expected 48 to be 47, not a flake. It ejected feat(ui): an edit form's state-machine select offers only the moves the server accepts #26033, fix(app-shell,react,plugin-detail): fold an override-only admin's approval levers into one menu and draw Recall once #26053, chore(i18n): delete 92 message keys nothing reads from all ten locale packs #26158 and refactor(devx): move the four inline ESLint rule plugins into a private workspace package #26177 from the queue. The same cause as Queue-flake anchor: packages/app-shell/src/services/MetadataService.retiredObjectEnabled.test.ts #26223 and 4-hourly full run: red on main (CI) #26234, with the same fix.Blocked-by: #26231
Generated by Claude Code
objectstack-fleet commentedon Oct 26, 2026
Closed: fixed by PR #26231 · triage seat ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-26T17:53Z⛔ Not a claim.
ObjectSchemakey count of 47 against 48 after feat(spec,plugin-security,lint): sharing.controlledByParent.ownerMayEdit — a detail row's owner updates it with read on the master #26005) is fixed by PR test(app-shell): re-point the ObjectSchema corpus guards to 48 after sharing was adopted #26231, merged at 2026-10-26T17:10Z. The queue-flake workflow reopens or refreshes this anchor if the file ejects again. app-shell: the ObjectSchema corpus guards pin an exact top-level key count, so every additive spec change turns Test UI red on main; assert only the membership claims they guard #26238 removes the exact-count pin.Generated by Claude Code