Skip to content

[finding] lint-startup-registry-verdict.corpus.test.ts sweeps 1872 files / 28.1 MB twice inside vitest's default 5s per-test timeout — ejected #10733 from the merge queue at 9.1s under queue load #10838

Description

@os-elon

What happened

Merge-queue CI run 32481624229 (2026-08-21 ~12:23Z, entry for PR #10733) failed on Test Core (4/6):

FAIL src/lint-startup-registry-verdict.corpus.test.ts > startup open-vocabulary verdicts across packages/ (#4776) > no package records a verdict the boot can still contradict
Error: Test timed out in 5000ms.

Actual duration 9144ms (file total 9731ms); 1 failed / 2250 passed on the shard. PR #10733 was ejected from the queue; its diff is describe/message prose in packages/spec — it does not touch packages/lint. The PR passed on requeue, consistent with a near-threshold timeout, not a regression.

Why this is structural, not incidental

packages/lint/src/lint-startup-registry-verdict.corpus.test.ts (#4776, the vocabulary gate):

  • The corpus is every non-test .ts under packages/ — on the current main that is 1,872 files, 28.1 MB.
  • The sweep (synchronous readFileSync of the whole corpus + findStartupRegistryVerdicts over each file) runs twice: once in no package records a verdict the boot can still contradict and again, from scratch, in no ledger entry is stale. Nothing is shared between the two cases.
  • Each case sits under vitest's default 5000ms per-test timeout — no testTimeout override anywhere in the file or the package config.

So the time budget is fixed while the work grows with the repo and the wall-clock varies with shard load. Queue builds run the full suite on loaded runners (this shard reported import 106.30s); 9.1s for a 28 MB synchronous read-and-scan there is unsurprising. The margin only shrinks from here.

Context: this is currently the only unfixed repeat-risk queue signature

A sweep of all 262 completed merge-group CI runs in the 24h window ending 2026-08-21T12:45Z: 256 success, 6 failures (2.3%), every one PR-independent (all six PRs passed on requeue). Of the six:

Each ejection also rebuilds every queue entry behind it (e.g. pr-10358 ran CI 5×), so a single flaky signature multiplies full-suite load. Precedent for the class: #6855 (ordering assertion failing under merge-queue load, ejecting unrelated PRs).

Possible shapes for a fix (for whoever picks this up — not prescribed)

  1. Hoist the corpus read + sweep into a shared beforeAll (or module-level) computation so the 28 MB scan runs once per file, and both cases assert over the cached findings. Halves the work and moves it out of the per-test budget (beforeAll gets its own hook timeout, which can be set explicitly).
  2. And/or declare an explicit per-file testTimeout sized to the corpus (with a comment tying the number to the corpus size so it reads as a decision, not a magic constant).
  3. Keep the two false-green refusals the file is built around (non-empty corpus, the sweep can still fire) intact — nothing here argues for weakening the gate, only for paying its cost once and budgeting it honestly.

Filed unassigned per findings discipline. The merge-queue triage bot will auto-open a cross-PR aggregate if a second distinct PR hits this signature; this card exists because the structural cause is already diagnosed and doesn't need a second ejection to be actionable.

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions