5

I am writing e2e tests on Detox to test a Firebase app in React Native. It looks like the call to firebase.auth().signInWithPhoneNumber(number) dispatches some items on the dispatch queue but these items don't ever seem to be dequeued and therefore the tests cannot proceed. My hunch is that there is a network request being made by the sign in call that never resolves. Here is the log:

detox[41991] INFO:  [APP_STATUS] The app is busy with the following tasks:
• There are 2 work items pending on the dispatch queue: "Main Queue (<OS_dispatch_queue_main: com.apple.main-thread>)".
• Run loop "Main Run Loop" is awake.

I have read through this troubleshooting guide and it looks like the operation is on the Main thread (native) and the issue is a waiting too much issue.

Is there a way to inspect the items on the dispatch queue to further understand what they are? I have tried running the /usr/bin/xcrun simctl spawn <device> log stream --level debug --style compact --predicate 'process == "myapp"' but I don't understand the output. If it is useful I can upload the logs.

I'm hoping I can post some logs of some sort and someone can help me to find the reason for the items on the dispatch queue or point me in the right direction. I have no experience with native development so device system logs and Objective C/Swift code mean nothing to me. Thanks

  • Detox version: 19.4.2
  • React Native version: 0.67.4
  • Node version: v12.22.6
  • Device model: iPhone 11 Simulator
  • OS: iOS
  • Test-runner (select one): jest-circus
dazzaondmic
  • 345
  • 4
  • 14

1 Answers1

3

To answer the question: No,there is no easy way to inspect the dispatch queue. You must go through the internals of the app, add logging, and comment-out portions of the code until you figure out what is causing the issue.

EDIT: As of 2022-08-07, updating your @react-native-firebase/* packages to >=v15.3.0 should fix the issue.

About your specific synchronization problem...

This problem is caused by a bug in the @react-native-firebase/messaging implementation of application: didReceiveRemoteNotification: fetchCompletionHandler:[!].

Their implementation gets into a race with FIRAuth/didReceiveRemoteNotification which causes react-native-firebase/messaging to not callback the completion handler if FIRAuth's function ran first.

A PR is in progress for this to be fixed upstream, but in the meantime you can use the following patch if you have set-up patch-package:

diff --git a/node_modules/@react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m b/node_modules/@react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
index ec26b70..743fe41 100644
--- a/node_modules/@react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
+++ b/node_modules/@react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m
@@ -123,6 +123,18 @@ - (void)application:(UIApplication *)application
     completionHandler(UIBackgroundFetchResultNoData);
     return;
   }
+
+  // If the notification is a probe notification, always call the completion 
+  // handler with UIBackgroundFetchResultNoData.
+  //
+  // This fixes a race condition between `FIRAuth/didReceiveRemoteNotification` and this
+  // module causing detox to hang when `FIRAuth/didReceiveRemoteNotification` is called first.
+  // see https://stackoverflow.com/questions/72044950/detox-tests-hang-with-pending-items-on-dispatch-queue/72989494
+  NSDictionary *data = userInfo[@"com.google.firebase.auth"];
+  if (data && data[@"warning"]) {
+      completionHandler(UIBackgroundFetchResultNoData);
+      return;
+  }
 #endif
 
   [[NSNotificationCenter defaultCenter]

[!]in @react-native-firebase/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m

Gabriel L.
  • 46
  • 8