fix(core): torn-down runtimes stop checking readiness, and entry tests fit their timeout under load

[miguel-heygen]

What

The runtime entry tests no longer time out on a loaded machine; the fix is at the cause, not a longer timeout. Making that change exposed a runtime bug, also fixed here.

• src/runtime/entry.test.ts: the runtime is evaluated once while the file loads, then reset. Each test still evaluates a fresh copy after vi.resetModules(), exactly as before.
• src/runtime/init.ts: a torn-down runtime no longer runs its readiness check. The check scheduled at start (setTimeout(..., 0)) survived teardown. When it fired after a new document loaded, it wrote __renderReady and could add an hf-timelines-built listener for the dead runtime. maybePublishRenderReady now returns once the runtime is torn down; every caller routes through it, the timer included.

Why

Every entry test re-imports the runtime after vi.resetModules(), which is how it models a page evaluating the runtime script again. The first of those imports also transforms the whole runtime module graph. That one-time cost (about 1-1.4 s on an idle machine) landed inside the first test's 5 s timeout, so under CPU contention paints no timed clip, from script evaluation until the first visibility pass decides it timed out, and the next test sometimes did too. File loading has no per-test timeout, so the transform now happens there.

Related work

None.

How

resetRuntimeGlobals is the old afterEach body, extracted so the load-time evaluation can clean up with the same steps. The readiness guard follows the state.tornDown early returns the runtime already uses elsewhere.

Test plan

• Idle machine, entry.test.ts alone: first test 922-1439 ms on main, 73-211 ms with the change, 31/31 passing, 3 runs each.
• Loaded machine (full src/runtime suite, vitest and four busy loops pinned to the same four cores): on main the entry file failed 2 tests in all 3 runs (first test 5055-5129 ms, "Test timed out in 5000ms"). With the change it passed in all 3 runs (first test 1331-2384 ms).
• New test a torn-down runtime's pending readiness check leaves the next document alone: passes 3 runs in a row. With the guard removed it fails with expected false to be undefined (the old check marked the next document not ready). init.test.ts 210/210 and entry.test.ts 31/31 pass.
• oxfmt --check, the comment citation check and the comment ratchet pass.

Not in this PR: under the same load, the first test in init.mediaClipIndex, init.swapScenes, init.timingResolver and audioClockSource, and one in transportPark, still time out, on main and on this branch alike. They do not re-import anything. Their cost is the first runtime start in a fresh test file, a different cause, so they get their own fix.

Size

Under 100 lines on purpose: a flaky test is fixed the day it is found, and nothing open carries this change.

[github-actions]

Edit accuracy: accurate 1216 (base branch 1216), smooth 1077 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (1)

• seqnudge-none-pct-r0-nested-z100 (fixed by fix(studio): playhead keyframe edits keep their ease, undo names its edit and never waits on videos #4889): pass, passes

[jrusso1020]

Approving at c704912b.

The flake is fixed at its cause. It came from the one-time module-graph transform landing inside the first test's 5 s timeout, not from runtime ordering. Every test still calls vi.resetModules() and imports ./entry fresh (32 of these imports for 31 tests), so each test still gets its own copy of the runtime. The new load-time evaluation is torn down with the same steps as afterEach. That means the first test starts from the same leftover state tests 2 to 31 already started from.

Coverage is unchanged. I turned hideTimedClipsUntilFirstPass into a no-op on both base and head, and the same 17 entry.test.ts tests fail in both, including "paints no timed clip…". The first test still catches a broken first-pass hide.

Suite time is unchanged. Running entry.test.ts alone on an idle box, the first test takes 74 ms here against 744-748 ms on base. The whole file takes about 2.75 s on both, because the cost moved into import. It wasn't removed.

The init.ts guard is a real fix, not something that hides a bug. The readiness check scheduled at start survived teardown and could write __renderReady on the next document. Every caller goes through maybePublishRenderReady, including the 0 ms timer and the hf-timelines-built path, so the single early return covers them all. If I remove it, the new test fails ("a torn-down runtime's pending readiness check leaves the next document alone"). init.test.ts and entry.test.ts pass 241/241 locally.

— Rames