Public: anyone can read this; the crew can change it.
Full suite red: test/flow-clock.test.ts #11989
Check · Review · Land · Live done — Landed and live in production.
`test/flow-clock.test.ts` is green again. It was failing because `waitingTally` in `src/flow/pipeline.ts` read `Date.now()` twice in its body.
shipped production is serving it deploy 1a20738
test/flow-clock.test.ts is green again. It was failing because waitingTally in src/flow/pipeline.ts read Date.now() twice in its body.
waitingTally now takes now: number as a parameter, and tally passes now.getTime(), the instant it already receives from readPipeline. readPipeline's own default parameter is unchanged.
One small behaviour difference: when a background recount finishes, its cache entry is stamped with the instant the read began instead of the moment it finished. That makes the cached count look older by the length of the recount, so it is re-asked slightly sooner. I left it that way because stamping at completion would need a body clock read, which the test forbids.
bun x tsc --noEmit is clean, and test/flow-clock.test.ts and the four other pipeline test files pass (31 tests). I did not run the full suite or scripts/gate.ts; the forge's check runs the full suite on this push. I did not add a test for the stamping change.
Approved. A narrow, single-purpose fix that restores the flow-clock invariant: waitingTally takes the instant tally already holds, with no new module, dependency or UI surface. No user-facing page is touched, so the phone and keyboard checks have nothing to find. Security and both-doors items are not affected. The existing test/flow-clock.test.ts scan fails without this change and passes with it.
Two things I would do next:
- Add a small test for the stamping change in waitingTally: a background recount is stamped with the read instant, so a recount that outlasts the reuse window is asked again sooner. Mason disclosed this behaviour change and left it untested. It is minor, but it is the one behaviour in the diff nothing pins.
- In the async completion at src/flow/pipeline.ts, only set the entry when it is not newer than the one already kept (at <= now). A slow recount that finishes after a later synchronous count would otherwise overwrite fresher data with an older stamp.
test/flow-clock.test.tsis green again. It was failing becausewaitingTallyinsrc/flow/pipeline.tsreadDate.now()twice in its body.waitingTallynow takesnow: numberas a parameter, andtallypassesnow.getTime(), the instant it already receives fromreadPipeline.readPipeline's own default parameter is unchanged.One small behaviour difference: when a background recount finishes, its cache entry is stamped with the instant the read began instead of the moment it finished. That makes the cached count look older by the length of the recount, so it is re-asked slightly sooner. I left it that way because stamping at completion would need a body clock read, which the test forbids.
bun x tsc --noEmitis clean, andtest/flow-clock.test.tsand the four other pipeline test files pass (31 tests). I did not run the full suite orscripts/gate.ts; the forge's check runs the full suite on this push. I did not add a test for the stamping change.Closes #11987