Disputable logic when SDK switches ConnectionState to reconnecting

[bombruch]

Environment:
SDK version: 2.0.19
iOS: any
Reproduces on minimal UIKit SDK example: yes

Steps to reproduce:

1. Configure ConnectOptions by default except 2 params:

ConnectOptions(
	reconnectAttempts: 30,
	reconnectAttemptDelay: 1
)

2. Connect to room
3. Turn off any internet connection and observe logs/publishers/delegate methods.

Current behaviour (CB):
CB1) SDK:
30 retries every ~second and disconnect after ~30 seconds. Under the hood: SDK makes 29 quick reconnects.

Logs

... 2025-02-25T15:03:55+0300 debug LiveKitSDK : [LiveKit] Room.startReconnect(reason:nextReconnectMode:) [Connect] Retry in 1.0 seconds, 26/30 tries left. 2025-02-25T15:03:55+0300 debug LiveKitSDK : [LiveKit] Room.quickReconnectSequence() [Connect] Starting .quick reconnect sequence... ...

and last one as full reconnect. SDK switches ConnectionState to reconnecting only when full reconnect is performed.

Logs

... 2025-02-25T15:03:59+0300 debug LiveKitSDK : [LiveKit] Room.startReconnect(reason:nextReconnectMode:) [Connect] Retry in 1.0 seconds, 30/30 tries left. 2025-02-25T15:03:59+0300 debug LiveKitSDK : [LiveKit] Room.init(delegate:connectOptions:roomOptions:) connectionState: .connected -> .connected, reconnectMode: Optional(.full) 2025-02-25T15:03:59+0300 debug LiveKitSDK : [LiveKit] Room.fullReconnectSequence() [Connect] starting .full reconnect sequence... 2025-02-25T15:03:59+0300 debug LiveKitSDK : [LiveKit] Room.init(delegate:connectOptions:roomOptions:) connectionState: .connected -> .reconnecting, reconnectMode: Optional(.full) 2025-02-25T15:03:59+0300 debug LiveKitSDK : [LiveKit] Room.cleanUp(withError:isFullReconnect:) withError: nil, isFullReconnect: true ...

CB2) Apps that use SDK and as a result user interface:
Clients see no changes so for ~29 seconds user can observe that everything is OK and only during last second user can see reconnecting state.

Expected behaviour:
SDK changes ConnectionState to reconnecting as early as possible.

Proposed updates:

• switch to reconnecting state after first quick reconnect
• or expose ReconnectMode as delegate and/or publisher. So clients can observe and react to it
• or may be add more ConnectionState - quickReconnecting and fullReconnecting
• or any other options that can help to get reconnect info without any SDK hacks.

[pblazej]

Thank you for reporting that!

The global state should be the source of truth, so both .quick and .full are covered by .reconnecting

• We could introduce another delegate method for ReconnectMode then
• However, this would be a breaking change for apps relying on .quick not being reflected
• Deprecating enum case will force consumers to handle that anyway

[pblazej]

Duplicate of #368

[ZayYarHtun]

@pblazej From this workaround #642, client can observe the reconnecting state for ReconnectMode/quick, but how can observe it's been reconnected?

[pblazej]

@ZayYarHtun thank you for pointing that out, the method mentioned in API docs won't be called on completion, ongoing fix: #825