Claude 860bde8842 fix(stream): close replay race, cursor-efficient resume, bounded client bookkeeping ... Three review findings, all valid: 1. Race: log-then-emit instead of emit-then-log The previous ordering emitted the live WS frame first and appended to Redis afterward. A client disconnecting in that window and reconnecting before the append completed would issue resume-stream, see nothing newer, and never ask again — permanently losing that frame (most painfully the terminal done:True frame). Inverted the order: the log is now the source of truth for what was "sent", and the live emit follows. A reconnect that races the append now may see a replayed frame before the live frame arrives in the new session, but the seq idempotency guard in chatEventHandler drops the duplicate harmlessly. Duplicates are safe; losses are not. 2. Resume reads no longer full-scan XADD now uses an explicit stream ID of `0-{seq}` (the per-emitter seq counter guarantees strict monotonicity), so _stream_log_read can start XRANGE at `0-{after_seq+1}` and let Redis skip entries already delivered. Near-tail resumes (the common case) go from O(MAXLEN) to O(missed frames). Dropped the now-redundant seq field from the stream entries and the Python-side seq filter — the envelope still carries seq internally for client-side idempotency. 3. Client map is now pruned resumeSeqByMessageId was growing unboundedly across the session. Now: - cleared on loadChat (chat switch) - cleared on initNewChat (new chat) - individual entries deleted in chatCompletionEventHandler's done:true branch (most messages evict quickly this way) Long-lived sessions no longer accumulate dead keys for every completed message they've ever seen.		2026-04-14 21:34:44 +00:00
..
main.py	fix(stream): close replay race, cursor-efficient resume, bounded client bookkeeping	2026-04-14 21:34:44 +00:00
utils.py	refac	2026-03-22 05:48:05 -05:00