Claude 4cc28eabff fix(stream): gate resume on REALTIME mode, chat ownership check, strict request_id match ... - resume_stream now short-circuits when ENABLE_REALTIME_CHAT_SAVE is on, mirroring the write-side gate in _stream_seq_allocate. Without this, stale logs written before the flag was flipped (or by a mixed-version peer) could still replay on top of DB-backed content and double-apply. - Added optional chat-ownership check: if the client sends chat_id, we validate via Chats.get_chat_by_id_and_user_id and reject on failure. Defense-in-depth alongside the user-scoped key. Fails OPEN when the chat lookup errors or chat_id is absent, so we don't regress the "stub not persisted in DB" refresh scenario that motivated removing the earlier stricter check. Frontend updated to include chat_id in the resume payload. - Client now requires an exact request_id match when expected is set. A reply without a request_id used to fall through and clear the active fence, which could prematurely flush a newer in-flight request's buffer. Now rejects both missing and mismatched. Deferred: suggestion to prune resumeSeqByMessageId on per-message terminal events. That was intentionally removed two rounds ago because the same pattern caused continuation-reuses-message_id to replay duplicate content. The memory footprint is int-per- message bounded by chat size and is cleared at chat/navigation boundaries — this is a deliberate trade-off, not an oversight.		2026-04-15 07:01:02 +00:00
..
main.py	fix(stream): gate resume on REALTIME mode, chat ownership check, strict request_id match	2026-04-15 07:01:02 +00:00
utils.py	refac	2026-03-22 05:48:05 -05:00