Bound the work-queue durability claim to the appendfsync window
Redis runs with appendfsync everysec, so an unclean stop loses up to a second of journaled entries. Name that where the docstrings promised a crash costs nothing, and state the setting and its trade-off on the configuration page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CL9zvnnvcp1mvA8o7impxk
This commit is contained in:
@@ -5,6 +5,10 @@ poll — becomes a work item before anything runs. The item is journaled first
|
||||
and acknowledged only once the wave it started has quiesced, so an engine that
|
||||
dies mid-cascade picks the work up again on the way back rather than losing it.
|
||||
|
||||
Redis journals with ``appendfsync everysec``, so the bound is the last second:
|
||||
an unclean stop of Redis or of its host loses up to a second of entries. An
|
||||
engine that dies while Redis lives loses none of them.
|
||||
|
||||
Two implementations: Redis Streams, which is what makes the above true, and an
|
||||
in-memory one for tests and for running without Redis, where "durable" degrades
|
||||
honestly to "not".
|
||||
|
||||
Reference in New Issue
Block a user