Concurrent transport teardown: cleanUp() nulls publisher/subscriber after awaiting dispose()
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 静か
調査の方向性
Start with test/race/teardown_race_test.dart to reproduce the concurrent teardown, then read engine.dart around cleanUp() and restartConnection(), plus room.dart around _cleanUp() and listener creation. Compare the race scenarios with the transport disposal paths; done means concurrent pc.close() calls are serialized and the regression test passes.
索引モデルが issue の本文から書いたものです。
説明
Environment
livekit_client 2.11.0 · flutter_webrtc 1.6.0 · reproduced in the package's own test harness (no device needed)
Summary
Engine.cleanUp() nulls the transport fields after awaiting dispose():
await publisher?.dispose(); // engine.dart:289 — suspends inside pc.close()
publisher = null; // engine.dart:290 — only after it returns
A concurrent caller entering during that await still sees publisher non-null and calls dispose() on the same object. Disposable correctly guards the second dispose of the same transport — but that guard returns immediately, so the second cleanUp() overtakes the first and tears down the other transport while the first is still inside pc.close(). Two RTCPeerConnection.close() calls end up in flight at once, which never happens when the paths run sequentially.
Three uncoordinated writers touch those fields: cleanUp() (:289), restartConnection() (:1211-1217, a near-copy), and Room._cleanUp() via :1079. Room's engine listener is created with createListener() (room.dart:183) — unsynchronized — so Room's handlers do not serialize either.
Reproduction
test/race/teardown_race_test.dart on the branch below. Real Room + real Engine, mock socket and peer connection; the tracing peer connection's close() spans several event-loop turns to model the blocking native close.
| scenario | concurrent pc.close |
double-dispose |
|---|---|---|
| S1 give-up branch alone | 1 | 0 |
S2 give-up ‖ room.dispose() |
2 | 2 |
S3 pending reconnect + disconnect() |
1 | 0 |
S4 two EngineDisconnectedEvents |
2 | 2 |
S2 is ordinary public API: the SDK gives up reconnecting while the app disposes the Room. S4 is reachable because the give-up branch never sets _isClosed = true (unlike :1014 and :1473), leaving the engine free to emit a second disconnect.
Your own log line is the tell — the baseline run prints !! [Transport#…] unnecessary dispose() called. (disposable.dart:55).
A fix that looks sufficient and is not
Locking cleanUp() alone still fails S2, because restartConnection() bypasses it. Confirmed by intervention, not by reasoning.
Suggested fix (branch ready, happy to open a PR)
Extract _disposeTransportsLocked() that detaches before awaiting, route cleanUp() and restartConnection() through one Engine lock, and give Room._cleanUp() its own. synchronized is already a direct dependency (used by event.dart).
The probe fails on pristine v2.11.0, passes with the change, and the full suite stays green (402 passed).
Branch: https://github.com/Kyra-H-I/client-sdk-flutter/tree/fix/serialize-transport-teardown
What we have not established
Whether this causes a specific native crash. We hit an iOS EXC_BAD_ACCESS that turned out to be a separate, already-fixed WebRTC-SDK bug (webrtc-sdk/webrtc@f47af7bc9658, shipped in 144.7559.10). This race may be a trigger for that class of fault — the faulting path requires a redundant stop — but we cannot prove it, and we are reporting the race on its own merits.
- 主要言語
- Dart
- スター
- 421
- フォーク
- 260
- 平均マージ
- 2日 5時間
- マージ済み PR(30日)
- 17
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
livekit/client-sdk-flutter のほかの issue
-
`jwtPayload.video` returns null grants for tokens from LiveKit server SDKs対応中かも @RaphaelFakhri が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
livekit/client-sdk-flutter#1236 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
livekit/client-sdk-flutter#1227 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
livekit/client-sdk-flutter#1221 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
livekit/client-sdk-flutter#1219 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
iOS: `audioDeviceModule` becomes permanently `nil`/unavailable after backgrounding, even though `AVAudioSession` is never interrupted対応中かも @hiroshihorie が 28 日前に担当しました。 オープン
livekit/client-sdk-flutter#1206 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
livekit/client-sdk-flutter の issue をすべて見る
似ている issue
-
Mobile login: "Sign In" button is squashed to 16 px with its label cut while the keyboard is openオープンai-driven-qa bug claude
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
linagora/tmail-flutter#4976 ·
メンテナーはふだん 1 日以内に返信
-
P2 package platform-ios team-ios
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
dart-lang/sdk#64568 · コメント 1 件 ·
メンテナーはふだん 4 日以内に返信
-
discover
難易度 2/5 1〜3時間 初心者へのやさしさ 91/100
DevDogsUGA/DogPack#14 ·
-
direct-code
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
aaronified/fluenough#500 ·
メンテナーはふだん 1 日以内に返信