Scene sky-change test: stay inside the timeout under load (bake each sky once) #162
Loading…
Reference in a new issue
No description provided.
Delete branch "void/scene-test-flake"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up
ratatoskr:follow_up:chat-mind-20261114T014146289Z-t13. The flaky test issrc/app/features/scene/index.test.ts"a sky change at any point of a build...".Cause: a timeout in the test, not a race in the scene. The test sweeps 21 microtask offsets; each iteration builds up to three scenes, and
createRidgeSceneis mocked butridgeSkyForis not, so every build bakes the real physical sky (atmosphere LUTs, tens of ms). Alone it takes 3.4 s against vitest's 5 s default; any CPU load (the full suite, another job) pushes it past: "Test timed out in 5000ms", captured under a 6-way concurrent run. No assertion failed, so the scene code (Nibu's) is not implicated and is untouched.Fix: the test bakes each state's sky once (a memoizing wrapper around
ridgeSkyForfor the single-argument call; the clock is fixed inbeforeEach, so a state always draws the same sky). Each build still receives the skyridgeSkyFormakes for its state; assertions are unchanged. The sweep now takes well under a second.Evidence: before, 1 failure in 30 runs under 6-way load (and the 1-in-3 seen in the full suite on a loaded machine); after, 48 of 48 pass under the same 6-way load, plus 22 clean runs alone. Mutation: removing the stale-build check (
mine !== generation) inindex.tsstill fails the test, so it still bites; restored.Test file only. Docs/scene code untouched.
🤖 Generated with Claude Code
Soul pass 1: NOT READY: with the memoized bake the stand-down guard in
rebuild(if (getSkyState() !== next) return;) was only caught by the old slow bakes, so removing it passed. Fixed: a new deterministic test pins it (exactly two builds for day then dusk; fails 3/3 under that mutation). Soul pass 2: READY; seven further mutations of index.ts fail the new file at least as often as the original. Known gap that predates this PR: removingoff()fromdisposepasses both files.