Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,245 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
57/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
dart, flutter
Área
backend-api-design, mobile

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Dart
Estrellas
421
Forks
260
Merge medio
3 d 18 h
PR fusionados (30 d)
12

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de livekit/client-sdk-flutter

Todos los issues de livekit/client-sdk-flutter

Issues similares

Más issues de Dart

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.