Claude cc8d1024a8 fix(stream): drop-vs-flush fence split; auto stream IDs; no truncate-at-start ... Two review findings: 1. clearAllResumeFences was firing unawaited async flushes from lifecycle transitions (disconnect, initNewChat, loadChat). That undermined the ordering guarantees the fence exists to provide, because the flushed events could land on a component that had already moved to a different chat or connection state. Split into two explicit verbs: - dropResumeFence / dropAllResumeFences — synchronous, no flush. Used in lifecycle transitions where the buffered events refer to state that is about to become stale. - clearResumeFence — async, flushes before dropping. Used by the replay-ack handler (happy path) and the fence timeout (safety). 2. Unconditional _stream_log_truncate at emitter creation could wipe an actively-streaming log if two emitters happened to overlap for the same (user_id, message_id). Removed the truncate entirely and switched XADD from explicit `0-{seq}` IDs to Redis-generated IDs, so overlapping emitters cannot collide on stream IDs regardless. seq now lives as a field on each entry and _stream_log_read filters by it in Python (full scan bounded by MAXLEN=2000, a few ms worst case, cost irrelevant for a user-driven event). Suggestion on replay payload size deferred: in practice resumes are tiny (handful of frames during a brief disconnect) and MAXLEN already caps the worst case at ~1MB. Chunking would add protocol complexity for a ceiling that isn't being hit. Easy to add later if telemetry shows real reconnect-storm spikes.		2026-04-14 22:11:37 +00:00
..
main.py	fix(stream): drop-vs-flush fence split; auto stream IDs; no truncate-at-start	2026-04-14 22:11:37 +00:00
utils.py	refac	2026-03-22 05:48:05 -05:00