Fix state handling issue in SignalClient

[holzgeist]

This PR solves a state handling issues in SignalClient on mobile clients (iOS in our case) when switching from mobile data to wifi.

This paragraph is an assumption from my side, feel free to correct me. When switching on Wifi, the operating system leaves the websocket connection open on mobile data to avoid reconnects. Due to high data volume, it kills the WebRTC connection though.

Now back to observations:

• When PCTransportManager notices the lost WebRTC connection, it initiates a reconnect event, which reaches SignalClient in line 214.
• this.state is set to RECONNECTING
• the rest of the reconnect logic is handled in connect
• if the websocket is still there (which it is, because it is still connected, sending pings and all), we close it in line 275
• Here comes the bug: close sets state to DISCONNECTING and to DISCONNECTED while cleaning up the websocket
• connect continues to setup a connection
• the server knows about the reconnect and sends a reconnect response right after the websocket connects
• line 358 should handle this, but only if state is still RECONNECTING
• By ignoring this message, state is stuck in DISCONNECTED, while the rest of the system repeatedly tries to initiate a connection

The fix is to skip state update in close if we are closing the websocket as part of a reconnection (i.e. from connect). We are already connecting, no need to set the state to DISCONNECTED.

[changeset-bot]

🦋 Changeset detected

Latest commit: b99d06e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
livekit-client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lukasIO]

thanks for the detailed report (and fix)!
yeah, that definitely seems to be a bug in the current implementation.

[holzgeist]

Awesome, thanks for the fast reaction and backport to v1!