fix(web): Improve WebSocket reconnection experience in Web UI#1669
fix(web): Improve WebSocket reconnection experience in Web UI#1669zgat wants to merge 2 commits intoMoonshotAI:mainfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e12de063e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (isReconnect) { | ||
| // Reconnect: preserve messages and slash commands | ||
| resetState(true, true); | ||
| } else { |
There was a problem hiding this comment.
This reconnect path preserves messages (resetState(true, true)), but the backend always replays persisted wire history on every WebSocket attach (src/kimi_cli/web/api/sessions.py calls replay_history when history exists). Because processEvent rebuilds chat entries with fresh client-side IDs, replayed turns are appended again instead of merged, so any reconnect (watchdog/network blip/manual reconnect) can duplicate the entire transcript and tool outputs in the UI.
Useful? React with 👍 / 👎.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| if (isReconnect) { | ||
| // Reconnect: preserve messages and slash commands | ||
| resetState(true, true); | ||
| } else { | ||
| // First connect: reset everything | ||
| resetState(true); | ||
| } |
There was a problem hiding this comment.
🔴 WebSocket reconnect duplicates all messages because history replay generates new IDs against preserved messages
On reconnect, connect({ isReconnect: true }) at web/src/hooks/useSessionStream.ts:2774 calls resetState(true, true) which preserves existing messages and does NOT reset isReplayingRef.current to true (lines 880-888). When the new WebSocket connects, the server replays all history events. Since isReplayingRef.current remains false, processEvent at line 2166 passes isReplay=false for every replayed event. Each event handler (TurnBegin at line 1083, ContentPart at line 1122, ToolCall at line 1222) calls getNextMessageId() which generates a fresh UUID via createMessageId (web/src/hooks/utils.ts:42). The upsertMessage function (web/src/hooks/useSessionStream.ts:808-816) searches by ID, finds no match against the preserved messages, and appends each replayed event as a brand-new message. The result is every message appearing twice in the UI after any WebSocket reconnection (triggered by network issues, watchdog timeout at line 2468, history_complete timeout at line 2097, etc.).
Before vs after this PR
The old code correctly handled reconnect by clearing messages:
resetState(true); // old: always reset isReplayingRef to true
setMessages([]); // old: clear messages before replayThe new code preserves messages but doesn't account for the server replaying history:
resetState(true, true); // preserveMessages=true: skips setMessages([]) AND skips isReplayingRef=truePrompt for agents
In web/src/hooks/useSessionStream.ts, the reconnect path at lines 2418-2424 calls resetState(true, true) which preserves messages but does NOT set isReplayingRef.current = true. When the server replays history on the new WebSocket, all events generate new client-side message IDs (via createMessageId/uuidV4) that don't match preserved messages, causing upsertMessage to append duplicates.
To fix this, you need one of these approaches:
1. (Simplest) In the resetState function around lines 880-888, when preserveMessages=true, still set isReplayingRef.current = true so that the server's history replay is processed with isReplay=true. Then after history_complete arrives, clear the old preserved messages and replace them with the freshly replayed ones. This requires tracking which messages came from the new replay vs the old preserved set.
2. (Alternative) Keep clearing messages on reconnect (revert to old behavior) and instead fix the scroll jump issue in VirtualizedMessageList separately — for example, by saving and restoring the scroll position after replay completes rather than trying to preserve the message array.
3. (Alternative) On reconnect, set isReplayingRef.current = true AND clear messages in resetState (like the old code), but immediately re-set isReplayingHistory to false after clearing so the VirtualizedMessageList doesn't trigger a scroll reset. The key={conversationKey} on Virtuoso won't change (same session), so scroll position may be naturally preserved.
Was this helpful? React with 👍 or 👎 to provide feedback.
- 重连时保留现有消息，不清空消息列表 - 重连时保持 isReplayingHistory 状态不变，避免触发滚动 - history_complete 时设置 isReplayingHistory(false) - 优化 VirtualizedMessageList 的 initialTopMostItemIndex 计算 - 添加静态文件到构建配置
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6ed2c2c8b3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Only reset replay state when clearing messages | ||
| isReplayingRef.current = true; | ||
| setIsReplayingHistory(true); |
There was a problem hiding this comment.
When reconnect calls resetState(true, true), this branch skips isReplayingRef.current = true, even though resetState still clears first-turn tracking refs. That makes replayed history events go through processEvent as non-replay events, so TurnBegin sets hasTurnStartedRef and a later idle session_status can fire onFirstTurnComplete again. In this repo, chat-workspace-container wires that callback to generateTitle, so a reconnect on any non-empty session can trigger extra title-generation calls and other non-replay side effects.
Useful? React with 👍 / 👎.
1 participant
Description
Optimize Web UI WebSocket reconnection experience to prevent message list flickering/jumping. Ensures no input content loss or scroll position reset after WebSocket reconnection.
Changes
• Preserve messages on WebSocket reconnection: No longer clears the message list when reconnecting, preventing users from seeing a blank page
• Optimize scroll behavior: Keep isReplayingHistory state unchanged during reconnection to avoid triggering automatic message list scrolling
• history_complete handling: Properly set isReplayingHistory(false) when receiving history_complete to prevent unexpected scrolling from subsequent state changes
• VirtualizedMessageList optimization: Use useMemo to cache initialTopMostItemIndex to avoid unnecessary recalculation
• Build configuration: Add [tool.hatch.build.targets.wheel] configuration to ensure static files are properly packaged
Technical Details
Technical Details
Core changes in useSessionStream.ts:
• resetState() adds preserveMessages parameter to preserve existing messages during reconnection
• connect() supports isReconnect option to distinguish between initial connection and reconnection scenarios
• Do not reset isReplayingHistory during reconnection to avoid triggering VirtualizedMessageList scroll logic
Checklist
I have linked the related issue, if any.(None)make gen-changelogto update the changelog.I have run(Not needed, internal optimization)make gen-docsto update the user documentation.