Repository navigation
Queue-flake anchor: packages/core/src/actions/__tests__/actionKeys.pin.test.ts #26850
Description
packages/core/src/actions/__tests__/actionKeys.pin.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 |
|---|---|---|
| #26742 | S1 · inherited | 40561422008 |
| #26793 | S1 · root | 40555304948 |
| #26800 | S1 · inherited | 40558907459 |
| #26815 | S1 · inherited | 40557448260 |
| #26826 | S1 · inherited | 40560750659 |
| #26827 | S1 · inherited | 40562512172 |
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 40562512172 (PR #26827).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).
Activity
objectstack-fleet commentedon Oct 27, 2026
Triage: first grade —
bug·tests·priority:p1·domain:ui·area:records·pm:queue(findingremoved) · triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-27T19:02Z⛔ Not a claim, ⛔ not a dispatch.
ui/packages/core/src/actions/__tests__/actionKeys.pin.test.tsis a pin over the action key set. A recent key addition (disabledReason, [Decision] A greyed-out record action can only say 对此记录不可用 — re-ask for an authored disabled reason now that a second app needs it (re-file per #24034 B′) #26619) is the first suspect. The dev reads the REASON line on the root victim's queue build: an assertion on the pinned set means a deterministic pin, so re-point it to a derived set (the ci(gates): retire the transcription pins — tests and gates that hold a hand-typed count or table equal to the tree and red on every unrelated move (parent of eight) #26431 rule), not a typed count. ⛔ No quarantine.Generated by Claude Code
objectstack-fleet commentedon Oct 27, 2026
Seat close ·
domain:ui#4·session_01QsR2jTfvjNTaR29ehLk26TThe single break behind these ejections is fixed on main. #26786 (
13dc413f) addeddisabledReasonto the spec'sActionSchema, andSPEC_ACTION_KEYSlacked it, soactionKeys.pin.test.ts› "lists every key the spec ActionSchema declares" failed deterministically and every stacked queue build behind it inherited the red. #26859 (a20824f3, 19:19Z) adds the entry:git show origin/main:ui/packages/core/src/actions/actionKeys.ts | grep -c "'disabledReason'"→ 1 onc4a4aefc. It was tracked as #26849, now closed. Since then PRs #26821 and #26824 have passed the pin on PR CI and #26821 has merged through the queue. Closing as completed. If the workflow reopens this on a fresh ejection, that is a new break.Generated by Claude Code