Claude d9e2ffc525 fix(stream): truncate stale resume log at emitter creation ... Fixes a silent-correctness gap flagged in review: explicit stream IDs of the form `0-{seq}` combined with a per-emitter seq counter that resets to 0 mean a second emitter for the same message_id (continuation, regeneration-into-same-id, or a retried producer after a crashed worker) would try to XADD `0-1` against a stream whose top item is `0-{N>1}`. Redis rejects the append, our try/except swallows it, and resume logging silently degrades exactly in the flows where resume matters most. Fix: when get_event_emitter is constructed, await a _stream_log_truncate for the message_id before any XADD. This guarantees our first XADD (`0-1`) is accepted and that the log reflects only the current run, not a mix of a crashed prior attempt and the retry. A background _delayed_truncate task from a previously-completed run is harmless here — it fires 30s after done:True on the OLD emitter, by which time either (a) no new emitter has started, in which case the delete is a legitimate cleanup, or (b) this new emitter has already truncated + started appending, in which case the delayed delete racing with the new run could wipe live data. To rule that out, the eager truncate at emitter start supersedes any pending delayed truncate for the same key; the next XADD then resets the stream, and when the new run's delayed truncate eventually fires, it just repeats the cleanup.		2026-04-14 21:42:30 +00:00
..
main.py	fix(stream): truncate stale resume log at emitter creation	2026-04-14 21:42:30 +00:00
utils.py	refac	2026-03-22 05:48:05 -05:00