Conversation
- Remove automatic interrupt on WebSocket close (sessions continue running) - Add AppState listener for mobile to reconnect when app returns to foreground - Add visibilitychange listener for web to reconnect when tab becomes visible - Add tests for WebSocket disconnect behavior Sessions now persist when user backgrounds app or closes tab. On return, client automatically reconnects and reloads messages to show any updates that occurred while disconnected. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Fix React hook dependency array issues causing listener re-registration - Use refs to track state without triggering effect re-runs - Check for CLOSED/CLOSING states instead of just !OPEN - Reload messages BEFORE reconnecting WebSocket (sequential, not parallel) - Add isReconnecting state with visual indicator (yellow dot) - Track wasBackground/wasHidden state to only reconnect when returning Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| role: 'assistant', | ||
| content: parts.filter(p => p.type === 'text').map(p => p.content).join(''), | ||
| id: `msg-done-${Date.now()}`, | ||
| parts, | ||
| }]) | ||
| } | ||
| streamingPartsRef.current = [] | ||
| setStreamingParts([]) | ||
| setIsStreaming(false) | ||
| return | ||
| } |
There was a problem hiding this comment.
Bug: The mobile WebSocket reconnection handler is incomplete and misses critical message types like assistant, preventing streaming responses from being displayed after reconnecting.
Severity: CRITICAL
🔍 Detailed Analysis
The mobile reconnection logic in SessionChatScreen.tsx establishes a new WebSocket with an onmessage handler that is missing handlers for critical message types, specifically assistant, tool_use, and tool_result. While the main connect() function handles these types correctly, the separate reconnection logic does not. As a result, when a mobile user returns to the app and the WebSocket reconnects, they will not see any live streaming assistant responses or tool-related messages, even though the session continues on the backend. This breaks the core functionality of receiving real-time updates after a temporary disconnection.
💡 Suggested Fix
Refactor the mobile reconnection logic to reuse the main connect() function, similar to the web implementation. This will ensure the WebSocket uses the complete onmessage handler that processes all required message types, including assistant, tool_use, and tool_result.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: mobile/src/screens/SessionChatScreen.tsx#L393-L407
Potential issue: The mobile reconnection logic in `SessionChatScreen.tsx` establishes a
new WebSocket with an `onmessage` handler that is missing handlers for critical message
types, specifically `assistant`, `tool_use`, and `tool_result`. While the main
`connect()` function handles these types correctly, the separate reconnection logic does
not. As a result, when a mobile user returns to the app and the WebSocket reconnects,
they will not see any live streaming assistant responses or tool-related messages, even
though the session continues on the backend. This breaks the core functionality of
receiving real-time updates after a temporary disconnection.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8368477
1 participant
Summary
What this fixes
When a user backgrounds the mobile app or switches browser tabs, the WebSocket disconnects. Previously this killed the running Claude process, losing any in-progress work. Now:
Test plan
🤖 Generated with Claude Code