A roll covers the whole store (rollBound() is max(rowid) with no ceiling) and a roll that misses ROLL_TIMEOUT_MS truncates nothing, so each failure hands the next attempt a strictly larger job under the same budget. Failure is total — there is no partial commit — so any condition that keeps a roll from finishing compounds rather than decays.
Raised by the reliability and adversarial passes on signalk-parquet-history-provider#13. Deferred from that PR because the ratchet only starts once rolls are already failing, and #13 closes the latches that start them. What is left needs a design answer rather than a patch:
- How big is one roll allowed to be — a rowid window, a row count derived from measured throughput, or one UTC day?
- Does a capped roll re-arm immediately so a backlog drains across several slots, or wait for the next slot?
- Does the timeout then become meaningful (exceeding it indicates a real problem rather than a large store)?
A roll covers the whole store (
rollBound()ismax(rowid)with no ceiling) and a roll that missesROLL_TIMEOUT_MStruncates nothing, so each failure hands the next attempt a strictly larger job under the same budget. Failure is total — there is no partial commit — so any condition that keeps a roll from finishing compounds rather than decays.Raised by the reliability and adversarial passes on signalk-parquet-history-provider#13. Deferred from that PR because the ratchet only starts once rolls are already failing, and #13 closes the latches that start them. What is left needs a design answer rather than a patch: