[Test] CoreStaticImports walks a 148-file import closure inside a test body, so bun's 5 s per-test default kills it under a loaded coverage run

[pathosDev]

Problem

tests/unit/CoreStaticImports.test.ts > core static import closure (#1005) > ActorSystem never statically reaches fastify failed inside a full gated run on 2026-08-29 (Windows, bun 1.4.0, ACTOR_TS_SKIP_FLAKY_MNS=1 bun run test:coverage:gate):

(fail) core static import closure (#1005) > ActorSystem never statically reaches fastify [6723.89ms]
  ^ this test timed out after 5000ms.

It passed in a full gated run earlier the same day and passes standalone, so this is load-dependence, not a regression. The invariant it guards — that import { ActorSystem } never statically reaches Fastify — is the #1005 gate, and an intermittently red gate is one people learn to re-run.

The deadline is not declared anywhere in the file. Neither test() takes a third argument, and bunfig.toml raises nothing, so the 5 000 ms is bun's per-test default — the same number tests/unit/ci/AwaitConditionBudgets.test.ts pins as BUN_DEFAULT_TEST_TIMEOUT_MS and re-measures against a spawned child run.

What runs against that cap is staticClosure('src/ActorSystem.ts'), called inside the test body: a breadth-first walk that reads every statically reachable source file and runs three matchAll passes over each.

Evidence

Measured in this worktree at 7fb9ca08, bun 1.4.0, Windows 11:

what	cost
the walk itself, src/ActorSystem.ts entry	26.2 ms — 148 files, 383 queue pops, 1.28 MiB of source
the walk itself, FastifyBackend.ts entry	1.6 ms — 7 files, 69 KiB
whole file, standalone bun test	276 ms
whole file, standalone bun test --coverage	82 ms
the failing test, in a full gated run	6 723.89 ms

So the walk is not slow: 26 ms of real work was observed taking 6.7 s, ~250x, because the whole suite was running around it. The failure reports the machine, not the invariant.

That this is the runner's cap and not something in the test is measurable directly. A fixture with 6 s of synchronous work at module scope and the identical 6 s inside a test body, one bun test run:

(fail) the same work inside a test body is killed at 5000ms [6000.16ms]
  ^ this test timed out after 5000ms.

 1 pass
 1 fail

The module-scope half passes — bun applies no per-test timeout to module load.

Why not simply declare a bigger third argument

That is the remedy AwaitConditionBudgets prescribes, and it is the wrong one here. A third argument is the right fix when the number being protected is a failure budget — a wait that is supposed to expire and print a label. This walk has no budget; it is bounded work that always completes. Any literal cap would be one more encoded assumption about machine speed, which is exactly the shared defect #1376 is open to remove — and it would have to be picked against a 250x observed spread.

The three sibling repo-file guards already do the right thing: tests/unit/ci/AwaitConditionBudgets.test.ts, tests/unit/ci/WorkflowHygiene.test.ts and tests/unit/config/NoDeadConfigKeys.test.ts all scan the tree at module scope and keep their test() bodies to assertions. CoreStaticImports.test.ts is the odd one out.

Related

• [Feature] Every testkit deadline is a hard millisecond literal — no global factor scales them for slow machines #1376 — the global scale factor for testkit deadlines. Adjacent but does not cover this: there is no testkit deadline here, and tests/util/TimerTolerance.ts today offers only TIMER_QUANTUM_MS and minimumElapsedMs(), both lower bounds for measured elapsed time. Nothing scales an upper bound.
• [Test] DocSampleHarnessEndToEnd flakes roughly one run in three — its beforeAll runs two synchronous bunx tsc compiles with no explicit timeout #1282 — the same failure family (expensive work in a hook against an unset cap), different file.
• [Feature] Evaluate Bun 1.4 test-runner parallelization (--parallel/--isolate/--shard/--timings) for the suite #1332 — Bun 1.4 test-runner parallelization; would change the contention this depends on.

Noted while reading, not fixed here: tests/unit/TreeShaking.test.ts runs Bun.build in three test bodies with no explicit timeout, which is the same shape and considerably more expensive per call. It has not been observed failing; recording it so it is not rediscovered from scratch.

Acceptance criteria

• The closure walk no longer runs against bun's per-test default.
• Both assertions are unchanged — ActorSystem must still be proven never to statically reach FastifyBackend.ts or a bare fastify, and the canary must still prove the walker is not blind.
• The reason is written down at the site, with the measured numbers, so the walk is not moved back into a test body later.
• Green under ACTOR_TS_SKIP_FLAKY_MNS=1 bun run test:coverage:gate and under bun run test:stress scoped to the file.

[pathosDev]

Fixed on features/core-static-imports-per-test-cap (8ccea821), local only.

What landed

Both closures are walked at module scope; the two test() bodies are assertions and nothing else. The assertions themselves are untouched.

Choosing that over a larger third argument was not a style preference. Module scope carries no per-test timeout at all, and that was measured rather than assumed — one bun test over a fixture with 6 s of synchronous work at module scope and the identical 6 s inside a test body:

(fail) the same work inside a test body is killed at 5000ms [6000.16ms]
  ^ this test timed out after 5000ms.

 1 pass
 1 fail

The module-scope half passes. It is also the shape the three sibling repo-file guards already use — AwaitConditionBudgets, WorkflowHygiene and NoDeadConfigKeys all scan the tree at module scope — so this removes an inconsistency rather than adding a special case.

Per-test durations, junit reporter, idle machine:

test	before	after
ActorSystem never statically reaches fastify	29.145 ms	0.412 ms
the canary is a real one	1.235 ms	0.037 ms

The observed failure was 6 723.89 ms against ~29 ms of idle work, ~230x. The same 230x applied to 0.412 ms is ~95 ms, under 2 % of the 5 000 ms cap.

Verification

• ACTOR_TS_SKIP_FLAKY_MNS=1 bun run test:coverage:gate — green: 8430 pass / 38 skip / 0 fail across 536 files (185.34 s), aggregate 93.68 % vs floor 90 %, src/cluster/ 97.40 % and src/persistence/ 94.94 % both over their floors, exit 0.
• bun run test:stress -- --runs=20 tests/unit/CoreStaticImports.test.ts — 20/20 green, read from the per-run lines rather than the summary ([Bug] stress-test.mjs reports PASS over 0/16 green runs — a test that fails twice in one run falls out of both offender tables, so the nightly flake catalog cannot see it #1359).
• bun run typecheck:dev — green.

A verification step that proved nothing, recorded so it is not repeated

I tried to reproduce the failure directly by running the pre-fix file (restored from 7fb9ca08) and the post-fix file side by side under 12 concurrent CPU hogs, under --coverage. It did not reproduce: the pre-fix version still completed in 31.45 ms and passed.

So external CPU competition is not the condition. The trigger is in-process — the heap and coverage counters of a full 536-file bun test --coverage run — which means the cheap synthetic-load technique that works for the hook family (docs/.../diagnosing-flakes.mdx suggests running several copies of the file at once) does not transfer here. Anyone trying to characterise this class again should not spend the hour I did on it.

That does not weaken the fix, and it is worth being clear why: the mechanism is established by direct measurement rather than by reproduction. Whatever made a test body take 6.7 s, a test body is no longer where the walk runs. If the cost is I/O contention on 148 readFileSync calls, it now falls at module load, where no per-test cap applies.

The scoped stress run is subject to the same limitation and should be read the same way: the pre-fix file would also have been 20/20 green on an idle machine. It shows no regression, not an absence of the flake.

Follow-up not taken here

docs/src/content/docs/testing/diagnosing-flakes.mdx (EN + DE) catalogues this family one level away — "A budget the per-test timeout cannot reach" and "Real work in a hook, against a cap nobody set" — but has no entry for real work in a test body, where the remedy is neither a third argument nor a layered budget but moving the work off the clock. A third catalog row and section would fit.

I did not add it in a test-fix commit because the page carries ordinal prose anchors that an insertion can silently desynchronise in both languages: "The second family is found by reading" (EN :116) and "That is a fifth family" (EN :370), and the ## The catalog table's row order is referenced as "the section above" / "the previous section's remedy" from inside two sections. Worth doing deliberately, with both mirrors and those anchors re-read.

Also still unaddressed, from the issue body: tests/unit/TreeShaking.test.ts runs Bun.build in three test bodies with no explicit timeout — same shape, considerably more expensive per call, not yet observed failing.