Claude 21ef7557cd fix(stream): close replay/live race and drop taskIds gate ... Critical: replay and live frames can interleave on the client. Previously the seq dedupe guard would drop replay frames whose seq was already covered by a racing live frame that arrived first, permanently losing the content between last_seq and the racing live seq. Fix with a replay fence scoped per message: - Server tags replay frames with `_replayed: true` and emits a `resume-stream:complete` event after the last one. - Client sets a fence (empty queue) BEFORE emitting resume-stream, so any live frame arriving while the server reads XRANGE is buffered — not applied, not advancing lastSeq. - Replay frames (`_replayed: true`) bypass the fence, apply in order, advance lastSeq. - On `resume-stream:complete`, client flushes the buffered live frames in seq order. The dedupe guard naturally drops any that were already covered by replay. Warning: removed the `taskIds && taskIds.length > 0` gate from the loadChat resume trigger. getTaskIdsByChatId is not an authoritative source of "should we resume" — it can fail, race, or return stale data, which would leave in-progress assistant messages unrecovered. requestResumeForAllInProgress already filters to assistants with done !== true, and the server replay is a no-op when no log exists, so the gate was only adding fragility.		2026-04-14 22:00:33 +00:00
..
main.py	fix(stream): close replay/live race and drop taskIds gate	2026-04-14 22:00:33 +00:00
utils.py	refac	2026-03-22 05:48:05 -05:00