iOS: intermittent deadlock between DTXSyncManager and JSTimerSync dispatch queues (currentStatus hangs indefinitely)

[tpaulshippy]

Description

We're seeing an intermittent full hang of the Detox<->app bridge during iOS e2e test runs (Detox 20.51.4, iOS 26.2 simulator, React Native 0.81.5, Expo SDK 54). When it happens, a currentStatus request to the app times out (no response within 5000ms), and the app never becomes responsive again for the rest of the test run (we've observed native/Detox-side unresponsiveness lasting 4-5+ minutes, until Jest's own hook/test timeout eventually fires).

Using sample (Xcode command line tool) to capture native, all-thread stacks of the app process at the moment of the hang, we found a circular deadlock between two of Detox's own internal serial dispatch queues:

Thread on com.wix.DTXSyncManager queue (computing a status/busy-resources query)

1760 Thread_45094   DispatchQueue_28: com.wix.DTXSyncManager  (serial)
+ 1760 start_wqthread  (in libsystem_pthread.dylib) + 8
+   1760 _pthread_wqthread  (in libsystem_pthread.dylib) + 288
+     1760 _dispatch_workloop_worker_thread  (in libdispatch.dylib) + 692
+       1760 _dispatch_root_queue_drain_deferred_wlh  (in libdispatch.dylib) + 288
+         1760 _dispatch_lane_invoke  (in libdispatch.dylib) + 396
+           1760 _dispatch_lane_serial_drain  (in libdispatch.dylib) + 984
+             1760 _dispatch_client_callout  (in libdispatch.dylib) + 12
+               1760 _dispatch_call_block_and_release  (in libdispatch.dylib) + 24
+                 1760 __46+[DTXSyncManager statusWithCompletionHandler:]_block_invoke  (in DetoxSync) + 36
+                   1760 +[DTXSyncManager _syncStatus]  (in DetoxSync) + 56
+                     1760 +[DTXSyncManager busyResourcesDescriptions]  (in DetoxSync) + 92
+                       1760 -[NSArray(Functional) map:]  (in DetoxSync) + 228
+                         1760 -[DTXJSTimerSyncResource jsonDescription]  (in DetoxSync) + 180
+                           1760 __detox_sync_dispatch_sync  (in DetoxSync) + 184
+                             1760 _dispatch_sync_f_slow  (in libdispatch.dylib) + 160
+                               1760 __DISPATCH_WAIT_FOR_QUEUE__  (in libdispatch.dylib) + 364
+                                 1760 _dispatch_event_loop_wait_for_ownership  (in libdispatch.dylib) + 532
+                                   1760 _dispatch_kq_poll  (in libdispatch.dylib) + 216
+                                     1760 kevent_id  (in libsystem_kernel.dylib) + 8

This thread is inside -[DTXJSTimerSyncResource jsonDescription], doing a synchronous dispatch (__detox_sync_dispatch_sync -> dispatch_sync_f_slow) onto the com.detox.sync.JSTimerSync queue, and is blocked waiting for it.

Thread on com.detox.sync.JSTimerSync queue (running a timer cleanup callback), at the same moment

1760 Thread_45628   DispatchQueue_32: com.detox.sync.JSTimerSync  (serial)
+ 1760 start_wqthread  (in libsystem_pthread.dylib) + 8
+   1760 _pthread_wqthread  (in libsystem_pthread.dylib) + 288
+     1760 _dispatch_workloop_worker_thread  (in libdispatch.dylib) + 692
+       1760 _dispatch_root_queue_drain_deferred_wlh  (in libdispatch.dylib) + 288
+         1760 _dispatch_lane_invoke  (in libdispatch.dylib) + 396
+           1760 _dispatch_lane_serial_drain  (in libdispatch.dylib) + 304
+             1760 _dispatch_source_invoke  (in libdispatch.dylib) + 1808
+               1760 _dispatch_continuation_pop  (in libdispatch.dylib) + 776
+                 1760 _dispatch_client_callout  (in libdispatch.dylib) + 12
+                   1760 __50-[DTXJSTimerSyncResource scheduleCleanupForTimer:]_block_invoke  (in DetoxSync) + 372
+                     1760 __detox_sync_dispatch_async  (in DetoxSync) + 136
+                       1760 -[DTXDispatchQueueSyncResource addWorkBlock:operation:moreInfo:]  (in DetoxSync) + 356
+                         1760 +[DTXSyncManager performUpdateWithEventIdentifier:eventDescription:objectDescription:additionalDescription:syncResource:block:]  (in DetoxSync) + 424
+                           1760 _dispatch_sync_f_slow  (in libdispatch.dylib) + 160
+                             1760 __DISPATCH_WAIT_FOR_QUEUE__  (in libdispatch.dylib) + 364
+                               1760 _dispatch_event_loop_wait_for_ownership  (in libdispatch.dylib) + 532
+                                 1760 _dispatch_kq_poll  (in libdispatch.dylib) + 216
+                                   1760 kevent_id  (in libsystem_kernel.dylib) + 8

This thread is inside a scheduled timer cleanup (-[DTXJSTimerSyncResource scheduleCleanupForTimer:]), which calls -[DTXDispatchQueueSyncResource addWorkBlock:operation:moreInfo:] -> +[DTXSyncManager performUpdateWithEventIdentifier:...], which does a synchronous dispatch back onto the com.wix.DTXSyncManager queue, and is blocked waiting for it.

Result: DTXSyncManager queue is doing dispatch_sync onto JSTimerSync, while JSTimerSync queue is doing dispatch_sync onto DTXSyncManager at the same time - a classic circular wait deadlock between two serial queues. Every other thread in the app (main thread, JS thread, websocket thread, etc.) is also blocked, all funneling through +[DTXSyncManager performUpdateWithEventIdentifier:...] waiting on the same wedged DTXSyncManager queue.

We confirmed this is a stable, persistent deadlock (not a momentary snapshot artifact) by taking multiple samples ~14 seconds apart during the same hang - the exact same two-thread deadlock stack was present in both.

Why this seems to be a genuine race, not something we can control

• It happens rarely/intermittently (we see it roughly 1 in 10-20 runs of the same suite), consistent with needing an unlucky timing overlap between (a) a currentStatus/busy-resources query starting to enumerate all DTXJSTimerSyncResources, and (b) one of those timers' scheduled cleanup callback firing on the JSTimerSync queue, at the same moment.
• It doesn't appear tied to any particular number of JS timers in the app - it doesn't require a "timer leak"; a single ordinary, short-lived timer completing at the wrong moment appears to be enough to trigger the race.
• Setting detoxEnableSynchronization: 0 as a launch arg does not prevent it, since Detox's own internal status-query/timer-tracking machinery still runs and races regardless of whether test actions wait on busy state.
• We're on the latest Detox release (20.51.4); this appears to still be present there.

Environment

• Detox: 20.51.4
• React Native: 0.81.5
• Expo SDK: 54
• Platform: iOS Simulator (iPhone 17, iOS 26.2), Xcode 26.3.0
• Test runner: Jest (jest-circus), maxWorkers: 1

Reproduction

Unfortunately we don't have a minimal, reliable repro - this is an intermittent race in a large e2e suite. We were able to capture it directly with the native sample tool running in a loop (every 10s) alongside our CI test runs, which is how we got the stacks above. Happy to share more samples/context if useful.

[huszzsolt]

We are successfully using Expo: 57.0.12, RN: 0.86.2, Detox: 20.51.3,
but to avoid synchronisation issues, we have 3 patches:

-detox

diff --git a/node_modules/detox/src/devices/runtime/RuntimeDevice.js b/node_modules/detox/src/devices/runtime/RuntimeDevice.js
index 3cc2640..aa9ac0c 100644
--- a/node_modules/detox/src/devices/runtime/RuntimeDevice.js
+++ b/node_modules/detox/src/devices/runtime/RuntimeDevice.js
@@ -208,6 +208,12 @@ class RuntimeDevice {
 
   async sendToHome() {
     await this.deviceDriver.sendToHome();
+    // RN 0.85 / Expo 56: didEnterBackground is not observed reliably; waitForBackground hangs.
+    if (this.getPlatform() === 'ios') {
+      await new Promise(resolve => setTimeout(resolve, 1000));
+      return;
+    }
+    // end RN 0.85 / Expo 56 patch
     await this.deviceDriver.waitForBackground();
   }
 

-react-native-webview

diff --git a/node_modules/react-native-webview/apple/RNCWebViewImpl.m b/node_modules/react-native-webview/apple/RNCWebViewImpl.m
index 7f5c24d..0c2e808 100644
--- a/node_modules/react-native-webview/apple/RNCWebViewImpl.m
+++ b/node_modules/react-native-webview/apple/RNCWebViewImpl.m
@@ -1872,7 +1872,9 @@ didFinishNavigation:(WKNavigation *)navigation
       if(!_incognito && !_cacheEnabled) {
         wkWebViewConfig.websiteDataStore = [WKWebsiteDataStore nonPersistentDataStore];
       }
-      [self syncCookiesToWebView:^{}];
+      if (_webView != nil) {
+        [self syncCookiesToWebView:^{}];
+      }
     } else {
       NSMutableString *script = [NSMutableString string];

-expo-app-metrics

diff --git a/node_modules/expo-app-metrics/ios/NetworkRequests/NetworkRequestTaskSwizzling.swift b/node_modules/expo-app-metrics/ios/NetworkRequests/NetworkRequestTaskSwizzling.swift
index 9d81881..4dd3ecd 100644
--- a/node_modules/expo-app-metrics/ios/NetworkRequests/NetworkRequestTaskSwizzling.swift
+++ b/node_modules/expo-app-metrics/ios/NetworkRequests/NetworkRequestTaskSwizzling.swift
@@ -113,6 +113,15 @@ enum NetworkRequestTaskSwizzling {
 
   /// Installs the swizzles. Idempotent — guarded by `installed` so repeat calls are no-ops.
   static func install() {
+    // DetoxSync also instruments URLSession / URLSessionTask (see NSURLSession+DTXSpy).
+    // Stacking our DelegateProxy + resume/setState swizzles on top breaks Detox's network and
+    // RN bundle-load idle detection ("React Native (bundle load)" never clears). Skip under Detox;
+    // E2E builds do not need HTTP request metrics. Same class of conflict as Flipper's network
+    // observer, which Detox already disables via disableFlexNetworkObserver.
+    if NSClassFromString("DTXSyncManager") != nil {
+      return
+    }
+
     state.withLock { installed in
       if installed {
         return

Your deadlock might come from somewhere else, but maybe the above help...