A printer pacing test asserts on wall-clock time
Todo2026-10-27jp
bounded_latency_controller_drains_large_queue_quickly, in crates/jp_printer/src/printer_tests.rs, prints 200 characters through the typewriter and asserts the drain takes less than 2 s. On 2026-10-21 it failed twice on macOS, once during the full workspace run and once on its own, at 25 s and 24.7 s. It passed in 1.7 s when run on its own again shortly after, with no change in between.
Why it is fragile
Its comment expects the drain to take about 200 ms. By the code it takes about 1 s: flush leaves the controller in live mode, so the per-character delay, min(50 ms, 200 ms / pending), grows from 1 ms toward 50 ms as the queue empties, and the 200 delays add up to about 0.96 s. That leaves the 2 s limit about twice the time the test needs.
The 25 s failures come to 125 ms per character, longer than any delay the controller asks for, so something stretched the timed waits themselves. Timer coalescing on macOS would explain it, but that is unconfirmed.
Suggested change
Test what the controller decides rather than how long the waits take. DelayControl::effective_delay is pure, so the delay it returns for a given queue depth, budget, and drain state can be asserted exactly. Keep at most one end-to-end check, with a limit far enough from the expected time that it only catches a controller that stopped shrinking the delay.