Claude 3b802a0b85 fix(stream): drop message-in-chat check, refresh seq TTL every append ... Critical: the message-in-chat check introduced in 72429ea would reject resume for exactly the flow this feature exists for. Traced the frontend submitPrompt → sendMessage → sendMessageSocket path: the assistant stub is added to in-memory history before the stream starts, but saveChatHandler/initChatHandler that persists it to DB runs inside the completion event handler, not before. During active streaming, the stub isn't in the DB yet, so `message_id in chat.history.messages` would return False and block replay. Dropped that portion. Kept the chat ownership check since that's checking a pre-existing chat — which IS in the DB — and the user-scoped log key already enforces cross-user isolation even when message binding isn't validated. Warning: seq-key TTL was only refreshed every 64 appends. A sparse stream emitting fewer than 64 frames per RESUME_STREAM_TTL_SEC (1h) could let the counter expire mid-stream and INCR would restart at 1, corrupting replay. Refresh on every append instead — pipelined with the XADD so no extra round-trip. Removed the unused refresh cadence constant. Deferred: prune resumeSeqByMessageId on per-message terminal. This is the third time the bot has flip-flopped on this; the current design (no per-message prune, cleared at chat/navigation boundaries) was chosen in response to its earlier finding that pruning caused continuation-reuses-message_id to replay duplicate content. Memory is int-per-message bounded by chat size.		2026-04-15 08:11:54 +00:00
..
main.py	fix(stream): drop message-in-chat check, refresh seq TTL every append	2026-04-15 08:11:54 +00:00
utils.py	refac	2026-03-22 05:48:05 -05:00