Public: anyone can read this; the crew can change it.
"/system over server-sent events > the sampler's clock runs only while someone watches, and ticks while they do" passes every time on a loaded check machine #5478
Check · Review · Land · Live done — Landed and live in production.
The sampler-clock test no longer sleeps, so a loaded machine can't make it fail. It passes `bun test --rerun-each 30 test/system-stream.test.ts`: 150 runs, 0 failures, on my machine. I could not check it on a loaded check machine. I did not get a type check: `bun x tsc --noEmit` reports no type definitions for `bun` here, and I did not follow that up.
shipped production is serving it deploy 1f09d72
The sampler-clock test no longer sleeps, so a loaded machine can't make it fail. It passes bun test --rerun-each 30 test/system-stream.test.ts: 150 runs, 0 failures, on my machine. I could not check it on a loaded check machine. I did not get a type check: bun x tsc --noEmit reports no type definitions for bun here, and I did not follow that up.
Cause: the test used a real 10 ms interval, slept 100 ms, and expected more than 2 ticks. On a loaded machine each tick reads /proc, and the timers can be starved, so fewer than 3 ticks fit in the window. The product code was correct: the clock starts with the first subscriber and stops with the last.
Change:
src/system/live.ts:createLivetakes an optionalschedulethat replacessetIntervalfor the push clock. The default is the same unref'd interval as before, so production behaves the same.test/system-stream.test.ts: the test now passes in a hand-crankedscheduleand fires it three times, expecting exactly three ticks. It also checks that the clock is cancelled when the last watcher leaves, once for each stop. Every assertion about starting, ticking and stopping is still there. The two sleeps and the "more than 2" bound are gone.
I left the other tests in that file alone.
🤖 Generated with Claude Code
The flaky sampler-clock test is now deterministic. The clock is injected through an optional schedule, and the default is the same unref-ed interval, so production behaviour is unchanged. The test cranks the clock by hand and still checks start, tick and stop, and now also that the clock is cancelled once per stop. I ran test/system-stream.test.ts here: 5 pass. The preview answers 200 on /. There is no UI, security or tty surface in this change. Two things to do next: (1) run bun x tsc --noEmit with types installed, since the author could not; (2) check whether other timing-based tests in the same file or in src/system should take the same injected clock.
The sampler-clock test no longer sleeps, so a loaded machine can't make it fail. It passes
bun test --rerun-each 30 test/system-stream.test.ts: 150 runs, 0 failures, on my machine. I could not check it on a loaded check machine. I did not get a type check:bun x tsc --noEmitreports no type definitions forbunhere, and I did not follow that up.Cause: the test used a real 10 ms interval, slept 100 ms, and expected more than 2 ticks. On a loaded machine each tick reads
/proc, and the timers can be starved, so fewer than 3 ticks fit in the window. The product code was correct: the clock starts with the first subscriber and stops with the last.Change:
src/system/live.ts:createLivetakes an optionalschedulethat replacessetIntervalfor the push clock. The default is the same unref'd interval as before, so production behaves the same.test/system-stream.test.ts: the test now passes in a hand-crankedscheduleand fires it three times, expecting exactly three ticks. It also checks that the clock is cancelled when the last watcher leaves, once for each stop. Every assertion about starting, ticking and stopping is still there. The two sleeps and the "more than 2" bound are gone.I left the other tests in that file alone.
🤖 Generated with Claude Code
Closes #5473