Queue-flake anchor: test/vitest-tiers-partition.test.ts

[github-actions]

test/vitest-tiers-partition.test.ts has ejected 5 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
#14443	S1 · inherited	33625162151
#14536	S1 · root	33623396688
#14538	S1 · inherited	33623834019
#14542	S1 · inherited	33623906645
#14543	S1 · inherited	33624604584

⚠️ Queue depth is not evidence. The 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 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.

Last refreshed by queue build 33625162151 (PR #14443).

---

Filed by the merge-queue-triage workflow (#4859, aggregation #10128).

[claude]

Reading from the domain:spec seat (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.ts is not on origin/main (53d3689) and is in none of the current queue trees (pr-14443, pr-14465, pr-14538, pr-14542, pr-14543 — checked by git ls-tree on each gh-readonly-queue/main/* ref). It exists only in PR test(cli): split the suite into named unit and integration vitest tiers #14536 ("the two tiers of packages/cli (pnpm --filter @objectstack/cli test is 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 unit and integration vitest tiers #14536 and docs(spec,approvals): ApprovalEscalation.timeoutHours names its clock — calendar (wall-clock) hours #14542, build 33623906645 on the old stack ccfa9556) share one cause: test(cli): split the suite into named unit and integration vitest tiers #14536's INTEGRATION_FILES omits packages/cli/src/utils/schema-migration-plugins.declaration-boot-write-guard.test.ts, which landed on main with fix(cli): close the declaration-boot write guard's two named boundaries — engine-held drivers and immediate DDL #14505 (c1f7e9f6, 10:07Z) and constructs new ObjectQL(...) (line 466) — exactly the [objectQLCtor] predicate hit the assertion prints. Every PR stacked behind test(cli): split the suite into named unit and integration vitest tiers #14536 inherited that red; docs(spec,approvals): ApprovalEscalation.timeoutHours names its clock — calendar (wall-clock) hours #14542 touches no packages/cli path.
• 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 unit and integration vitest tiers #14536 lands as is — the fix belongs to test(cli): split the suite into named unit and integration vitest 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 its INTEGRATION_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 1f456906 on b8a16be2) and needs no change.

---

Generated by Claude Code

[huangyiirene]

Triage — graded, finding cleared. 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 main

git ls-tree -r origin/main | grep vitest-tiers at b8562ff262 → nothing. The file is not in the tree.

It is added by PR #14536 — the row this anchor already marks S1 · root. Its body introduces packages/cli/test/vitest-tiers-partition.test.ts as the new pin for the unit/integration tier split, and lists it in its own unit file 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 inherited rows (#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_FILES equals the behavioural predicate re-derived from every test file's source. INTEGRATION_FILES is 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 a packages/cli test 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

1. Read one victim PR's triage comment for the REASON line beside the FAIL line. Start with test(cli): split the suite into named unit and integration vitest tiers #14536 — it is the root and it owns the file.
2. If the failure is test(cli): split the suite into named unit and integration vitest 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.
3. Close this issue with the fix or with the reason it is not one.

Routing

domain:cli — the file lands in packages/cli/test/, which is that lane. tests.

priority:p2 rather than the p3 its 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