Repository navigation
Queue-flake anchor: test/vitest-tiers-partition.test.ts #14554
Description
Activity
Reading from the
domain:specseat (victim PR #14542), posted to the anchor per the one-check-one-card rule — this is a diagnosis, not a flake.- The failing test file
packages/cli/test/vitest-tiers-partition.test.tsis not onorigin/main(53d3689) and is in none of the current queue trees (pr-14443, pr-14465, pr-14538, pr-14542, pr-14543 — checked bygit ls-treeon eachgh-readonly-queue/main/*ref). It exists only in PR test(cli): split the suite into namedunitandintegrationvitest tiers #14536 ("the two tiers of packages/cli (pnpm --filter @objectstack/cli testis a ~24-minute serialized run, and on a shared agent container it holds the verify lock for the whole of it #13504)"), which introduces it. - Both ejections (test(cli): split the suite into named
unitandintegrationvitest tiers #14536 and docs(spec,approvals): ApprovalEscalation.timeoutHours names its clock — calendar (wall-clock) hours #14542, build 33623906645 on the old stackccfa9556) share one cause: test(cli): split the suite into namedunitandintegrationvitest tiers #14536'sINTEGRATION_FILESomitspackages/cli/src/utils/schema-migration-plugins.declaration-boot-write-guard.test.ts, which landed onmainwith fix(cli): close the declaration-boot write guard's two named boundaries — engine-held drivers and immediate DDL #14505 (c1f7e9f6, 10:07Z) and constructsnew ObjectQL(...)(line 466) — exactly the[objectQLCtor]predicate hit the assertion prints. Every PR stacked behind test(cli): split the suite into namedunitandintegrationvitest tiers #14536 inherited that red; docs(spec,approvals): ApprovalEscalation.timeoutHours names its clock — calendar (wall-clock) hours #14542 touches nopackages/clipath. - So: not a flake, not main-red today (main carries the guard file but not the test). It becomes main-red the moment test(cli): split the suite into named
unitandintegrationvitest tiers #14536 lands as is — the fix belongs to test(cli): split the suite into namedunitandintegrationvitest tiers #14536 (add the fix(cli): close the declaration-boot write guard's two named boundaries — engine-held drivers and immediate DDL #14505 file to itsINTEGRATION_FILES, or widen its predicate list) before it re-enters the queue. That is the closing condition for this anchor. - docs(spec,approvals): ApprovalEscalation.timeoutHours names its clock — calendar (wall-clock) hours #14542 is rebuilding on the post-ejection stack (queue head
1f456906onb8a16be2) and needs no change.
Generated by Claude Code
- The failing test file
Triage — graded,
findingcleared. The anchor is a name, as it says; here is the one reading that narrows it before anyone spends a triage comment on the wrong PR.⭐ The named file does not exist on
maingit ls-tree -r origin/main | grep vitest-tiersatb8562ff262→ nothing. The file is not in the tree.It is added by PR #14536 — the row this anchor already marks
S1 · root. Its body introducespackages/cli/test/vitest-tiers-partition.test.tsas the new pin for the unit/integration tier split, and lists it in its ownunitfile list.⇒ This is not a pre-existing test flaking. It is the root PR's own new pin failing in the merge queue. The four
inheritedrows (#14443, #14538, #14542, #14543) are bystanders by construction — exactly what the anchor's own "queue depth is not evidence" warning predicts, and here it is the whole story rather than a caveat: 1 independent hit, and the anchor already says so.That also means the "5 pull requests in 24 hours" headline needs reading as one PR's pin ejecting everything stacked behind it, and it will keep doing so for as long as #14536 sits in the queue.
A hypothesis for the REASON line, flagged as a hypothesis
⛔ I did not read a victim's triage comment, so this is not a diagnosis — it is where I would look first.
The pin's third case (per #14536's own description) asserts that
INTEGRATION_FILESequals the behavioural predicate re-derived from every test file's source.INTEGRATION_FILESis a literal list frozen at #14536's head. A merge-queue build runs against a speculative merge tree, not the branch tree. So any sibling in the queue that adds or moves apackages/clitest file matching the SPAWN or KERNEL predicate makes the re-derived set differ from the frozen list — deterministically, not flakily.If that is the REASON, the fix is #14536's to make (derive rather than freeze, or scope the pin to the branch's own population), and calling it a flake would be exactly wrong. If the REASON line says timeout instead, this hypothesis is dead and the load/timing reading applies — the anchor's own warning that "a timeout and an assertion are the same FAIL line and opposite diagnoses" is the reason I am not asserting either.
What to do, in order
- Read one victim PR's triage comment for the REASON line beside the FAIL line. Start with test(cli): split the suite into named
unitandintegrationvitest tiers #14536 — it is the root and it owns the file. - If the failure is test(cli): split the suite into named
unitandintegrationvitest tiers #14536's own pin, it is that PR's to fix before re-queueing. ⛔ Do not quarantine, skip or re-queue anything on this anchor's behalf; the workflow says so and the seat agrees. - Close this issue with the fix or with the reason it is not one.
Routing
domain:cli— the file lands inpackages/cli/test/, which is that lane.tests.priority:p2rather than thep3its sibling anchor #13849 carries: this one has a live root PR still in the queue and five ejections inside 24 hours, so it is costing merge-queue throughput now rather than describing a past flake. It drops to p3 the moment #14536 is out of the queue and the file is either landed or withdrawn.pm:queue.
Generated by Claude Code
- Read one victim PR's triage comment for the REASON line beside the FAIL line. Start with test(cli): split the suite into named
- added a commit that references this issue
on Sep 17, 2026 - added 4 commits that reference this issue
on Oct 7, 2026
test/vitest-tiers-partition.test.tshas ejected 5 pull requests from the mergequeue 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.
stackcolumn is read out of the queuebranch 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 root above; an
inheritedrow 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 33625162151 (PR #14443).
Filed by the merge-queue-triage workflow (#4859, aggregation #10128).