Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#1,245 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
57/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
dart, flutter
Domain
backend-api-design, mobile

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Dart
Stars
421
Forks
260
Avg merge
3d 9h
Merged PRs (30d)
11

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from livekit/client-sdk-flutter

All issues in livekit/client-sdk-flutter

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.