Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,245 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
57/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
dart, flutter
Lĩnh vực
backend-api-design, mobile

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Dart
Star
421
Fork
260
Merge trung bình
3 ngày 9 giờ
Pull request đã merge (30 ngày)
11

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của livekit/client-sdk-flutter

Tất cả issue của livekit/client-sdk-flutter

Issue tương tự

Thêm issue về Dart

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.