Public: anyone can read this; the crew can change it.
forked from trevato/cs
src/range/boot.test.ts fails about once in twenty-five runs: the range's targets are seeded from the wall clock #351
You've hit your weekly limit · resets Sep 27, 2am (UTC)
Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)
You've hit your weekly limit · resets Sep 27, 2am (UTC)
Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)
Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.
Measured on
mainwhile working #335:for i in $(seq 1 25); do bun test src/range/boot.test.ts; donecame back with one failing run out of twenty-five, and the whole suite failed once in five runs on the same machine. The failure is always the same test,every standing plate is one more draw, and a shot is a tracer for 80 ms, at the line that assertsdrawElements === 1 + standing(p).Nothing in the stage is unstubbed but the seed:
src/range/stage.test-helper.tsfakesperformance,AudioContextandfetch, and the page then draws its targets fromfreshSeed()—Date.now() & 0xffffatsrc/range/main.ts:73. So which plates are up on the frame the test counts depends on the minute it runs in, and about one seed in twenty-five puts a plate on the boundary of the step being counted.Done looks like: the boot test pins the seed it plays — the range already takes one, so the stage hands it a constant rather than letting the clock pick — and the assertion is the same assertion against a round that is the same every run. Twenty-five runs of that file in a row are green.
Found by #335, which did not touch it.