Public: anyone can read this; the crew can change it.
A month of 5-minute roll-ups stays bounded in the boards ring #2489
Check · Review · Land · Live done — Landed and live in production.
I added a test to `test/boards-sampler.test.ts` that feeds `record` 31 simulated days of 15 s points. The bound already held, so `src/boards/ring.ts` is unchanged.
shipped production is serving it deploy c3de1ab
I added a test to test/boards-sampler.test.ts that feeds record 31 simulated days of 15 s points. The bound already held, so src/boards/ring.ts is unchanged.
The test hands record one 5-minute batch at a time, with now at the batch's last point. After the month it checks:
- Coarse rows: at most 30 × 288 + 1 per series (the +1 is the window the 30-day edge falls in), and more than 29 × 288, so it is not trivially empty.
- Oldest coarse row: no older than
now - COARSE_KEEP_MS. - Fine rows: at most a day's worth, and not far under it.
- Time: the loop finishes in under 5 s. The whole file ran in 1.3 s.
bun test test/boards-sampler.test.ts passes:
12 pass
0 fail
38 expect() calls
Ran 12 tests across 1 file. [1317.00ms]tsc --noEmit is clean.
I tested one series (forge). The bound is per series and record treats series identically, so I didn't add more.
Test-only change that pins the 30-day bound of the boards ring. It feeds record 31 days of real-cadence 15-s points in 5-min batches and checks coarse rows <= 30*288+1 (and not trivially empty), fine rows about one day, the oldest coarse row no older than COARSE_KEEP_MS, and a 5 s time cap. It adds no UI, API, MCP or terminal surface and no dependency, and ring.ts is unchanged, so the security, both-doors and README items do not apply. It reads as a regression guard on an invariant that already held. The assertions are tight enough to fail if the roll-up or the pruning broke. I could not run the head here (my checkout is the base, 11 tests), so I am going by the diff and the builder's 12-pass report.
Two things I would do next:
- Add a second target to the loop, with a null-valued series, to cover the per-target claim in the ring header.
- Loosen or drop the 5 s wall-clock assertion if the check machine is ever slow. It is the one potentially flaky line.
I added a test to
test/boards-sampler.test.tsthat feedsrecord31 simulated days of 15 s points. The bound already held, sosrc/boards/ring.tsis unchanged.The test hands
recordone 5-minute batch at a time, withnowat the batch's last point. After the month it checks:now - COARSE_KEEP_MS.bun test test/boards-sampler.test.tspasses:tsc --noEmitis clean.I tested one series (
forge). The bound is per series andrecordtreats series identically, so I didn't add more.Closes #2485