Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,245 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
57/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
dart, flutter
Ambito
backend-api-design, mobile

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Dart
Stelle
421
Fork
260
Merge medio
3g 9h
PR unite (30g)
11

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livekit/client-sdk-flutter

Tutte le issue di livekit/client-sdk-flutter

Issue simili

Altre issue su Dart

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.