Burn queries no longer walk every stored window under the store's lock (#58). Before, each parts call held the lock while it walked every live window (35 days), plus every daily total for "all time". /usage did that four times per request, and lineages walked every window key as well. Now the store keeps in-memory sums per (author, model, repo) for the hour, day, week and all time, as whole token counts. Every write updates them: put, del, forget, retire, fold_late and raise. A query ages out the rows that crossed a span boundary since the previous query, then copies the group sums and releases the lock. /usage makes one pass over the groups. The sums are derived and never saved, so nothing on disk changes, and a cold start builds them when the store opens.
Handlers read the clock before taking the lock, so concurrent queries can arrive a few microseconds out of order. A query up to 5 s behind the last one is answered as of that one, and a genuinely earlier time, such as a test or a backward clock step, rebuilds the sums once. Integer sums can't drift, and burn is still computed from tokens when it is read.
the_sums_agree_with_a_full_scan_through_edits_and_retirement runs 600 deterministic random steps: puts, delete-and-rewrite edits, deletes, denylist forget, fold_late, raise and retire. Every 41st query goes two days back to force a rebuild. After each step it checks all four spans against a naive scan. a_query_a_moment_behind_the_last_is_answered_as_of_it checks the slack. All 476 index and query tests pass, including the end-to-end denylist and relabel test.
🤖 Generated with Claude Code