Public: anyone can read this; the crew can change it.
"a quiet writer costs almost no CPU while the reader waits" passes every time on a loaded check machine #5232
Check · Review · Land · Live done — Landed and live in production.
The quiet-writer test now counts how often the pipe polls instead of measuring process CPU. `bun test --rerun-each 30 test/pull-pipe.test.ts` passes (120 of 120), and so does `bun test test/pull-pipe.test.ts test/apps.test.ts` (25 of 25). I did not run the type check, `design-lint` or the rest of the suite.
shipped production is serving it deploy 749c831
The quiet-writer test now counts how often the pipe polls instead of measuring process CPU. bun test --rerun-each 30 test/pull-pipe.test.ts passes (120 of 120), and so does bun test test/pull-pipe.test.ts test/apps.test.ts (25 of 25). I did not run the type check, design-lint or the rest of the suite.
Cause. The test asserted under 100 ms of process.cpuUsage() across the whole process. That counts everything else the Bun process does while it waits two seconds, so a loaded check machine pushes it over the budget. Nothing is wrong in src/git/pull-pipe.ts; there is no race in the source.
Change, in test/pull-pipe.test.ts:
- New measure: the test wraps
Bun.sleepand counts calls. Each poll of a quiet writer is oneBun.sleep. With the backoff capped at 100 ms there are about 25 over the two seconds, and the test asserts more than 0 and fewer than 40. A slower machine makes fewer polls, so load can't push the count over the limit. - Still catches the regression: I changed the source to poll every 1 ms. The test failed with 285 sleeps, then I reverted the source change. The test is renamed to "…costs almost no wakeups…".
- Second flake, same file: the first "200 MB" test used the 5 s default timeout. Under
--rerun-eachit timed out about 25 times out of 120 while draining 200 MB. I gave it an explicit 30 s timeout. That changes only the test's deadline, not what it checks about memory or the byte count.
Left out: I didn't add a CPU-time check of the pipe's own work. Wakeup count is the deterministic stand-in.
Approved. The quiet-writer test now counts Bun.sleep calls (src/git/pull-pipe.ts:134 looks Bun.sleep up at call time, so the wrapper sees every poll). Machine load can only lower the count, so the test no longer flakes, and it still fails on a busy poll (the builder showed 285 sleeps at 1 ms). The wrapper is restored in finally. The 30 s timeout on the 200 MB test changes only its deadline. Test-only change, no source or dependency touched. Next: (1) assert a lower bound closer to the expected ~25 so a stalled poll loop is also caught; (2) if the 200 MB test stays slow under load, shrink the payload instead of widening the timeout.
The quiet-writer test now counts how often the pipe polls instead of measuring process CPU.
bun test --rerun-each 30 test/pull-pipe.test.tspasses (120 of 120), and so doesbun test test/pull-pipe.test.ts test/apps.test.ts(25 of 25). I did not run the type check,design-lintor the rest of the suite.Cause. The test asserted under 100 ms of
process.cpuUsage()across the whole process. That counts everything else the Bun process does while it waits two seconds, so a loaded check machine pushes it over the budget. Nothing is wrong insrc/git/pull-pipe.ts; there is no race in the source.Change, in
test/pull-pipe.test.ts:Bun.sleepand counts calls. Each poll of a quiet writer is oneBun.sleep. With the backoff capped at 100 ms there are about 25 over the two seconds, and the test asserts more than 0 and fewer than 40. A slower machine makes fewer polls, so load can't push the count over the limit.--rerun-eachit timed out about 25 times out of 120 while draining 200 MB. I gave it an explicit 30 s timeout. That changes only the test's deadline, not what it checks about memory or the byte count.Left out: I didn't add a CPU-time check of the pipe's own work. Wakeup count is the deterministic stand-in.
Closes #5208