🤖 fix: self-heal stale chat subscriptions after sleep/wake #1356
+363
−23
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Problem: In mux server mode (browser UI), after idle time or sleep/wake, the chat UI can stop reflecting live stream state—you send a message, input clears, but nothing appears in the transcript. No connection warning shows, and refreshing the page reveals the conversation happened. Root cause: The transcript updates only via the workspace.onChat streaming subscription. If that async iterator silently stalls (common after sleep/wake or network changes), the RPC send succeeds but the UI never receives the events that drive the transcript. Solution: 1. **connectionEpoch tracking**: APIProvider increments an epoch on each new connection. WorkspaceStore restarts all subscriptions when the epoch changes, preventing stale iterators from the old connection. 2. **Subscription watchdog**: Monitors all chat subscriptions and auto-restarts them if: - No caught-up received within 15s (buffering stall) - Active stream has no events for 30s (stream stall) 3. **UI feedback**: New SubscriptionStatusIndicator shows "Reconnecting chat stream..." when a subscription is being restarted, so users know recovery is in progress. 4. **Diagnostics**: Added logging for WS close events (code/reason) and ping failures to help debug future connection issues. 5. **Storybook**: Added Chromatic story for the reconnecting banner. --- _Generated with `mux` • Model: `anthropic:claude-opus-4-5` • Thinking: `high`_
ibetitsmike
force-pushed
the
stream-sync-1qsn
branch
from
f00b756 to
b1b51e0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
In mux server mode (browser UI), after idle time or sleep/wake, the chat UI can stop reflecting live stream state:
Root Cause
The transcript is not updated optimistically on send; it updates only via the streaming subscription
workspace.onChat. Any failure where the async iterator stalls without ending/throwing produces exactly this UX: the RPC send succeeds, but the UI never receives thetype:"message"/ stream events that drive the transcript.Solution
1. connectionEpoch tracking
APIProviderincrements aconnectionEpochon each new connection.WorkspaceStorerestarts all subscriptions when the epoch changes, preventing stale iterators from the old connection.2. Subscription watchdog
Monitors all chat subscriptions and auto-restarts them if:
caught-upreceived within 15s (buffering stall)3. UI feedback
New
SubscriptionStatusIndicatorshows "Reconnecting chat stream…" when a subscription is being restarted, so users know recovery is in progress.4. Diagnostics
Added logging for WS close events (code/reason) and ping failures to help debug future connection issues.
Testing
make static-checkpassesGenerated with
mux• Model:anthropic:claude-opus-4-5• Thinking:high