Fix chat replay recovery during WebSocket reconnect (resubscribe)#1718
Fix chat replay recovery during WebSocket reconnect (resubscribe)#1718hwanseoc wants to merge 5 commits intopingdotgg:mainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ApprovabilityVerdict: Approved Bug fix that triggers existing replay recovery when WebSocket reconnects, ensuring chat events aren't lost. Changes are additive (new callback option), backwards-compatible, and well-tested. The author has recent commit history in the modified files. You can customize Macroscope's approvability policy. Learn more. |
Resolve the replay recovery merge conflict by keeping main's bounded replay retry logic and the PR's reconnect-triggered resubscribe recovery path. Co-authored-by: codex <codex@users.noreply.github.com>
|
picked your commits and extended the scope a bit in #1730 to improve the visibliity of the connection state |
Why
If t3code web is served over an unstable and frequent-reconnect network, there was a problem in chat replay recovery where the UI could stay stale until a manual refresh.
This change starts replay recovery on WebSocket resubscribe so missed chat/orchestration events are recovered as soon as the stream comes back.
What Changed
This fixes a blind spot in chat replay recovery after WebSocket interruption.
The client already handled sequence gaps and snapshot fallback for orchestration events, but it only recovered missed events when a later domain event arrived and exposed the gap. If the WebSocket dropped, the client missed the last chat/orchestration events, and the thread then went quiet, the UI could stay stale until a manual refresh.
This change adds reconnect-aware replay on orchestration stream re-subscribe so the client asks for missed events as soon as the stream is re-established.
Checklist
Note
Medium Risk
Touches the WebSocket subscription/retry path and orchestration recovery flow; incorrect resubscribe signaling could cause redundant replays or missed updates, but changes are scoped and covered by new tests.
Overview
Ensures orchestration/chat state catches up immediately after a WebSocket reconnect by triggering replay recovery on stream resubscribe (new recovery reason
"resubscribe").Adds an optional
onResubscribecallback plumbed through contracts (NativeApi),wsNativeApi,WsRpcClient, andWsTransport.subscribe, withWsTransportonly firing the hook after the stream has emitted at least one value; updates and extends tests to verify option forwarding and correct hook behavior.Reviewed by Cursor Bugbot for commit 9fbb588. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Fix chat replay recovery during WebSocket reconnect by triggering resubscribe recovery
onResubscribecallback support toWsTransport.subscribe, invoked on reconnection after at least one value has been received; errors are swallowed so recovery proceeds.onResubscribethrough the RPC client stream methods and up to theNativeApi.orchestration.onDomainEventcontract.EventRoutercomponent, theonResubscribehandler flushes pending domain events and triggers replay recovery with the new'resubscribe'reason, mirroring the existing'sequence-gap'path.'resubscribe'as a validOrchestrationRecoveryReasonand refactors sequence-gap recovery into a sharedrunReplayRecovery(reason)function.Macroscope summarized 9fbb588.