fix: wait for ReconnectResponse to arrive before declaring signal rec… - #2082
fix: wait for ReconnectResponse to arrive before declaring signal rec…#2082lukasIO wants to merge 2 commits into
Conversation
|
size-limit report 📦
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| if ( | ||
| this.lifecycleState === 'reconnecting' && | ||
| parsed.message?.case !== 'reconnect' && | ||
| parsed.message?.case !== 'leave' | ||
| ) { | ||
| this.log.warn('dropping signal message while awaiting reconnect response', { | ||
| messageCase: parsed.message?.case, | ||
| }); | ||
| continue; |
There was a problem hiding this comment.
🟡 Reconnect discards valid room updates
When parsed.message precedes the reconnect response, the client discards participant, track, room, and token updates. Room state can remain stale after resume.
Prompt for agents
During SignalClient.connect reconnect handling in src/api/SignalClient.ts, messages received before ReconnectResponse are currently consumed from the ordered stream and discarded. These messages can be legitimate server updates and will never appear in startReadingLoop. Preserve them while waiting for ReconnectResponse, then process them through handleSignalResponse after the reconnect has been validated and the lifecycle transition succeeds. Keep Leave handling immediate and ensure buffered messages from an abandoned or superseded attempt are not delivered into a later session. Add coverage proving an update before ReconnectResponse reaches its callback exactly once and in order.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
I think this is also my main question reading this, do you want to replay these updates prior to the ReconnectResponse after the ReconnectResponse is received? I would think so but I might be missing something.
There was a problem hiding this comment.
the server guarantees the ordering now. Any relevant updates that happen in between should be replayed by the server.
There was a problem hiding this comment.
Sounds good - maybe it's worth adding a comment inline mentioning this? That's not necessarily initially intuitive behavior from the client end IMO.
2 participants
…onnected