A full reconnect that is in progress when disconnect() is called reopens the closed engine and retries up to reconnectAttempts

Start in engine.dart at handleReconnect(), attemptReconnect(), restartConnection(), connect() and disconnect(); trace how an in-progress restart behaves when disconnect occurs during the awaited teardown. First reproduce with the held peerConnectionClose described in the issue, then check that disconnecting prevents any later joins or retries, including when the room still exists and the identity reconnects elsewhere.

Environment

• livekit_client 2.13.1 (pub.dev), flutter_webrtc 1.6.2+hotfix.4, Flutter 3.47.0
• livekit-server 1.13.9 (room.auto_create: false)
• Seen on an Android emulator during a network handover; reproduced on Windows desktop

Summary

If Engine.disconnect() (or Room.disconnect() / Room.dispose()) runs while a full reconnect has
passed the _isClosed check at the top of restartConnection() but has not yet reached its call to
connect(), the closed engine starts connecting again. connect() sets _isClosed = false
unconditionally, so every later guard sees an open engine, and the retry loop runs until the attempt limit
(10 attempts, about 50 to 64 s). Each attempt is a join with the old token and identity. When the room still
exists and the same identity has meanwhile joined from a new Room, one of these attempts succeeds and the
server removes the new, live participant with DUPLICATE_IDENTITY.

Code path (engine.dart, 2.13.1)

1. handleReconnect() (line 1075) schedules attemptReconnect() on a timer; for a full reconnect it calls
   restartConnection() (line 1195).
2. restartConnection() checks _isClosed only on entry (line 1325). It then emits
   EngineFullRestartingEvent (1330) and awaits the old peer connections' dispose, signalClient.cleanUp()
   and _signalListener.cancelAll() (1332 to 1352) before calling connect() (1354). These awaits are
   native calls; on an Android emulator one of them took 7.5 s.
3. During that window the app calls disconnect(): _isClosed = true (1631). It cancels only a pending
   retry timer (1636 to 1641), not the attempt that is already running. cleanUp() (309) calls
   _clearPendingReconnect() (330), which resets _reconnectAttempts to 0 (199 to 203). Room.dispose()
   then disposes the engine (222 to 228: _isClosed = true, events emitter disposed).
4. The suspended restartConnection() resumes and calls connect(), which sets _isClosed = false (251).
5. The connect fails (room gone, relay refusing, ...). attemptReconnect()'s catch increments the counter
   (1207) and calls handleReconnect() (1223). The guard at 1079 now sees _isClosed == false, so another
   attempt is scheduled. Every following restartConnection() passes 1325 and every connect() clears the
   flag again (251), until reconnectAttempts exceeded (1108 to 1118).
6. All events of these attempts go to the disposed emitter (failed to emit event ... on a disposed emitter),
   so the application cannot observe or stop them.

Reproduction

Real server, Windows desktop, one Room (A) whose signal WebSocket goes through a local TCP relay:

1. A connects (token identity u:x, room R).
2. Drop all relay connections and refuse new ones: the resume fails and the SDK starts a full reconnect
   (EngineFullRestartingEvent).
3. To widen the window of step 2 above deterministically, hold the first peerConnectionClose call on the
   FlutterWebRTC.Method channel after the drop (the full reconnect disposing the old publisher) until
   1 s after step 4 finished.
4. On RoomReconnectingEvent call room.disconnect() and room.dispose(); both complete.
5. Either delete room R (case "gone") or keep it and connect a second Room (B) with the same identity
   (case "kick"), then stop refusing at the relay.

Observed (livekit_client 2.13.1):

• "gone", 3 of 3 runs: 10 joins after the disconnect, then reconnectAttempts exceeded 48 to 50 s later.
• "kick", 5 of 5 runs: about 11.5 s after the disconnect one retry of the closed engine joins R; the server
  logs removing duplicate participant for B, and B gets RoomDisconnectedEvent(duplicateIdentity).
• Control: disconnecting while the retry timer is pending gives 0 joins (the timer is cancelled).

A smaller unit level reproduction with a fake signal server (answers /rtc with 401, 404
requested room does not exist, or accepts) and the same held peerConnectionClose shows 4, 3 and 1 joins
within 5 s after the disconnect.

Expected

After disconnect() / dispose() returns, the engine makes no further connection attempts.

Possible fixes

• Do not clear _isClosed in connect() when it is called from restartConnection(), or re-check
  _isClosed after each await in restartConnection() and right before connect().
• Let disconnect() stop an attempt that is already running (for example an attempt generation number
  checked after each await in attemptReconnect() / restartConnection()), not only the pending timer.
• cleanUp() from disconnect() resetting _reconnectAttempts makes the closed engine start counting from
  zero again; that is only visible because of the first point.

Workaround we use

A subclass of Engine passed to Room(engine: ...) overrides connect() to fail immediately once the
application has closed the session, before super.connect() can clear _isClosed. The failure is an
ordinary (retryable) error, so attemptReconnect() calls handleReconnect(), which stops at the
_isClosed guard (1079) because the flag is still set.

Related

• #1186 (concurrent transport teardown in cleanUp()), a different race in the same teardown path.