ScreenTinker bf9ad16486 The checkpointer startup line no longer describes a policy it stopped having ... It still read "escalate >16MB or 3 growing runs" after #240 added a size floor and a cooldown to that second rule. Growth-across-three-runs on its own is exactly the half that no longer holds, so the line described a checkpointer that does not exist — and it is the line an operator reads to learn the policy. During an incident it would send you hunting for a blocking checkpoint that the new gates had in fact suppressed. [wal-checkpoint] off-thread checkpointer started (PASSIVE every 15000ms; blocking TRUNCATE when the WAL exceeds 16MB, or after 3 growing runs but only at >=8MB and at most once per 300s; respawn max 5/60000ms) A test now asserts the line reports every knob that governs the decision, since nothing else keeps a log string and the rule it describes in step. Writing it caught its own bug first: anchoring the slice back to `return worker;` matched the idempotence guard at the top of startWalCheckpointer(), not the log below it, so the window was empty and every assertion passed vacuously. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS		2026-08-06 22:12:01 -05:00
..
database.js	#240: stop the morning wave buying itself a blocking checkpoint	2026-08-06 20:22:21 -05:00
schema.sql	Offline media on every player, and a revision so the cache can still be updated	2026-08-05 15:27:36 -05:00
wal-checkpointer-worker.js	#240: stop the morning wave buying itself a blocking checkpoint	2026-08-06 20:22:21 -05:00
wal-checkpointer.js	The checkpointer startup line no longer describes a policy it stopped having	2026-08-06 22:12:01 -05:00