iOS: AudioDeviceModuleObserver's DISPATCH_TIME_FOREVER waits can deadlock the JS thread (total UI freeze) under default config

[chen-rn]

Follow-up to livekit/client-sdk-react-native#389, where @jankosecki traced this deadlock and offered to file it here. We hit the same bug in production with the default configuration, so we're filing it with our data. All file/line references below are against the 144.1.0 tag.

Environment

• @livekit/react-native-webrtc 144.1.0, @livekit/react-native 2.11.0
• React Native 0.85.3 (New Architecture), Expo SDK 56
• iOS, physical device, production build
• Default audio setup: stock registerGlobals(), no autoConfigureAudioSession changes, no manual audio session configuration

Mechanism

Three pieces interact:

1. ios/RCTWebRTC/AudioDeviceModuleObserver.m blocks the native thread driving RTCAudioDeviceModule delegate callbacks with dispatch_semaphore_wait(..., DISPATCH_TIME_FOREVER) while waiting for a JS reply — six sites: L61 (didCreateEngine), L82 (willEnableEngine), L107 (willStartEngine), L128 (didStopEngine), L149 (didDisableEngine), L161 (willReleaseEngine). The reply only arrives if the JS thread is free to run the event listener and call the corresponding audioDeviceModuleResolve* method (WebRTCModule+RTCAudioDeviceModule.m:232-258).
2. The observer is installed unconditionally in WebRTCModule.m:98-99, so every app pays the blocking-wait cost even if it never registers JS-side audio engine hooks.
3. Several peer-connection methods are blocking-synchronous JS→native calls that dispatch_sync onto the serial workerQueue — notably peerConnectionAddTransceiver (WebRTCModule+RTCPeerConnection.m:534, dispatch_sync at L539), which holds the JS thread until the queue block returns.

If an AVAudioEngine stop/restart (e.g. a mic publish flipping the engine from playout-only to duplex) is in flight when JS enters peerConnectionAddTransceiver, the workerQueue block stalls inside libwebrtc on state held by the restart, the restart's delegate callback waits forever for a JS reply, and JS is parked inside the synchronous bridge call. Circular wait — JS → workerQueue → libwebrtc/ADM state → delegate semaphore → JS — and nothing ever proceeds.

Reproduction shape

Publish a microphone track and then a camera track back-to-back right after Connected (a voice+video call against a LiveKit agent, in our case). The mic publish triggers the playout-only → duplex engine restart; the camera publish issues the synchronous addTransceiver. The race window is a few milliseconds, so it's intermittent — most calls are fine, then one freezes. livekit/client-sdk-react-native#389 has the mirror-image trace from the subscribe side (remote audio+video tracks on join).

Production occurrence

UTC, from our backend records of the frozen call:

Time	Event
01:46:33.116	Last JS-side analytics write — JS thread provably alive
01:46:34.642	Agent subscribed our microphone track (mic publish completed)
—	Camera track never published
—	room.disconnect() never ran; user force-killed the app

In a healthy call by the same user two minutes earlier, the mic→camera publish gap was 35 ms.

Impact

Permanent app-wide UI freeze: the JS thread never returns, every React Native touchable is dead, and no crash report is generated since it's a deadlock rather than a crash. The user's only recourse is force-killing the app, and because room.disconnect() can never run, the session also lingers server-side.

Proposed fix

Bound the six waits (e.g. dispatch_time(DISPATCH_TIME_NOW, 2 * NSEC_PER_SEC)), drain any stale signal left on the long-lived semaphore by a previously timed-out round before sending the event, and on timeout emit an os_log error and return the default 0 so the engine operation degrades gracefully instead of freezing the app. We're running exactly this as a local patch in production. Happy to open a PR if the approach is acceptable.

[davidliu]

Temporary fixes in #90, #91. Leaving this issue open until the full fix is done.

[zer0-deaths]

Follow-up after 144.1.1 (#90 / #91): the deadlock is bounded but not gone

We're the team from the original report. Confirming behavior on 144.1.1 with the temporary fixes in place.

Environment (unchanged from the report):

• @livekit/react-native-webrtc 144.1.1, @livekit/react-native 2.11.0
• React Native 0.85.3 (New Architecture), Expo SDK 56
• iOS, physical iPhone 13 Pro, default audio config (stock registerGlobals(), no autoConfigureAudioSession changes)
• LiveKit JS client two-PC join (singlePeerConnection: false)

Since #90/#91 bounded the six ADM delegate waits to 2s, the permanent app-wide freeze is gone. But on every cold call we now hit a ~40-45s JS-thread stall during room.connect(), while the publisher PeerConnection fails to establish. The subscriber path stays alive throughout (agent data keeps arriving over a data channel), and the room only reaches connected after ~42-47s, via an internal reconnect.

Clearest single signal: a setTimeout(0) we schedule in our own RoomEvent.SignalConnected handler fires 38.5s late - the JS event loop is starved that long.

Sanitized timeline (tMs = ms since call start). Two consecutive cold calls, both reproduced:

call A:
+4084   room.connect() start  (singlePeerConnection:false, iceTransportPolicy:default, peerConnectionTimeout:5000)
+5465   RoomEvent.SignalConnected                 (websocket up, +1.4s)
+5466   (our iOS muted-mic publish is deferred to a later phase - not the trigger)
+27112  first agent data on data channel          (subscriber PC alive; room still "connecting")
~40000  JS thread stalled: stalledMs ~= 40873
+44011  setTimeout(0) from SignalConnected fires 38,546 ms late
+44072  could not establish Publisher connection, state: closed   (ConnectionError)
+44075..45922  publishData() retries -> "PC manager is closed"  (~10x)
+46128  RoomEvent.SignalConnected (reconnect)
+46735  ConnectionStateChanged -> connected        (first time the room is usable)
+46770  room.connect() resolves: room_connect.done after 42,686 ms

call B (next call): stall ~= 45,203 ms; setTimeout(0) 40,069 ms late; room_connect.done after 47,478 ms

Raw client/native lines during the stall (ids redacted):

leave-reconnect disconnected
websocket closed { code: 1001, reason: "Stream end encountered", wasClean: false }
signal disconnected
could not createOffer with closed peer connection
could not establish Publisher connection, state: closed   (ConnectionError)
PC manager is closed   (UnexpectedConnectionState)        [repeated ~10x]

We never publish video; the only local publish is a muted mic, and it's deferred until after this window - so this isn't the mic->camera race from the original repro. It's the publisher PC's initial negotiation stalling on its own. #90/#91 bounded the ADM delegate waits but left the synchronous peerConnectionAddTransceiver -> dispatch_sync(workerQueue) path (point 3 of the original report) unchanged, so our working theory is that JS is still parking on that synchronous bridge call while the worker queue is tied up in the publisher's playout->duplex audio-engine transition - now capped per-ADM-event at 2s instead of forever, which is why it recovers after tens of seconds instead of never.

Happy to provide full unredacted logs, a Hermes profile, or run an instrumented build to pin the remaining blocking site.