detoxEnableSynchronization argument not working on android.

[vliedel]

What happened?

When adding detoxEnableSynchronization: 0, to the launchArgs of launchApp(), it was still waiting for a network request. Manually calling disableSynchronization() afterwards is already too late for my use case. In this case, I could work around it with detoxURLBlacklistRegex, but that won't work for everything.

What was the expected behaviour?

Network request not being awaited.

Was it tested on latest Detox?

• [X] I have tested this issue on the latest Detox release and it still reproduces.

Did your test throw out a timeout?

• [X] I have followed the instructions under Identifying which synchronization mechanism causes us to wait too much.

Help us reproduce this issue!

No response

In what environment did this happen?

Detox version: 19.5.7 React Native version: 0.66.3 Node version: 12.22.7 Device model: Samsung Galaxy S8 Android version: 9 Test-runner (select one): jest-circus / jest+jasmine / mocha / other

Detox logs

Detox logs

paste logs here!

Device logs

Device logs

13:28:29.497 detox[17139] INFO:  [APP_STATUS] The app is busy with the following tasks:
• 1 network requests with URLs:
  - URL #1: http://10.27.8.232:3100/sse.
13:28:32.840 detox[17139] WARN:  [PENDING_REQUESTS] The app has not responded to the network requests below:
  (id = -1000) isReady: {}

More data, please!

No response

[jonathanmos]

@vliedel indeed it seems that there's a problem here. I'm adding it to the issues that we'll deal with in the near future

[MiguelAraCo]

I also encountered this issue. In our case there's an endless animation that we can't mock at the beginning of our application that prevents launchApp from ever resolving.

[d4vidi]

@jonathanmos should this be accepted? (triage=>accept)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.

Thank you for your contributions!

For more information on bots in this reporsitory, read this discussion.

[stale[bot]]

The issue has been closed for inactivity.

[TallPaulRyan]

I have been trying to disable synchronization during mobile app boot to bypass what I believe is a similar issue. In the logcat logs you will always see this behavior:

DEVICE LOGS (Sample): 07-11 16:15:45.614 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 400 iterations. 07-11 16:15:48.439 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 600 iterations. 07-11 16:15:49.902 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 700 iterations. 07-11 16:15:49.975 29101 29101 E Detox : No active CatalystInstance. Should never see this. 07-11 16:15:49.976 29101 29101 W IdlingPolicy: These resources are not idle: [com.wix.detox.reactnative.idlingresources.uimodule.UIModuleIdlingResource] 07-11 16:15:51.582 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 800 iterations. 07-11 16:15:53.218 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 900 iterations. 07-11 16:15:54.832 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 1000 iterations. 07-11 16:15:54.920 29101 29248 D DetoxWSClient: Received action 'currentStatus' (ID #2, params={}) 07-11 16:15:54.921 29101 29247 I DetoxDispatcher: Handling action 'currentStatus' (ID #2)... 07-11 16:15:54.922 29101 29101 E Detox : No active CatalystInstance. Should never see this. 07-11 16:15:54.923 29101 29247 I DetoxWSClient: Sending out action 'currentStatusResult' (ID #2) 07-11 16:15:54.924 29101 29247 I DetoxDispatcher: Done with action 'currentStatus' 07-11 16:15:54.976 29101 29101 E Detox : No active CatalystInstance. Should never see this. 07-11 16:15:54.977 29101 29101 W IdlingPolicy: These resources are not idle: [com.wix.detox.reactnative.idlingresources.uimodule.UIModuleIdlingResource] 07-11 16:15:56.401 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 1100 iterations. 07-11 16:15:58.034 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 1200 iterations. 07-11 16:15:59.712 29101 29101 W UiControllerImpl: Waiting for: DYNAMIC_TASKS_HAVE_IDLED for 1300 iterations.

DETOX LOGS 19:01:57.306 detox[78674] INFO: [APP_STATUS] The app is busy with the following tasks: • UI elements are busy:

• Reason: UI rendering activity. • There are enqueued timers. 19:02:07.353 detox[78674] INFO: [APP_STATUS] The app is busy with the following tasks: • UI elements are busy:
• Reason: UI rendering activity. • There are enqueued timers. 19:02:17.383 detox[78674] INFO: [APP_STATUS] The app is busy with the following tasks: • UI elements are busy:
• Reason: UI rendering activity. • There are enqueued timers. 19:02:27.393 detox[78674] INFO: [APP_STATUS] The app is busy with the following tasks: • UI elements are busy:
• Reason: UI rendering activity. • There are enqueued timers. 19:02:37.421 detox[78674] INFO: [APP_STATUS] The app is busy with the following tasks: • UI elements are busy:
• Reason: UI rendering activity. • There are enqueued timers. 19:02:47.436 detox[78674] INFO: [APP_STATUS] The app is busy with the following tasks: • UI elements are busy:
• Reason: UI rendering activity. • There are enqueued timers. 19:03:04.214 detox[78674] WARN: [APP_NONRESPONSIVE] Application nonresponsiveness detected! On Android, this could imply an ANR alert, which evidently causes tests to fail. Here's the native main-thread stacktrace from the device, to help you out (refer to device logs for the complete thread dump): com.github.anrwatchdog.ANRError: Application Not Responding for at least 5000 ms. Caused by: com.github.anrwatchdog.ANRError$$$_Thread: main (state = RUNNABLE) at android.os.MessageQueue.nativePollOnce(Native Method) at android.os.MessageQueue.next(MessageQueue.java:335) at java.lang.reflect.Method.invoke(Native Method) at androidx.test.espresso.base.Interrogator.getNextMessage(Interrogator.java:1) at androidx.test.espresso.base.Interrogator.loopAndInterrogate(Interrogator.java:10) at androidx.test.espresso.base.UiControllerImpl.loopUntil(UiControllerImpl.java:8) at androidx.test.espresso.base.UiControllerImpl.loopMainThreadUntilIdle(UiControllerImpl.java:17) at androidx.test.espresso.Espresso$1.run(Espresso.java:1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:462) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:223) at android.app.ActivityThread.main(ActivityThread.java:7656) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

Refer to https://developer.android.com/training/articles/perf-anr for further details.

In what environment did this happen? Detox version: 19.7.0 React Native version: 0.64.2 Node version: 16.14.2 Device model: Emulator, Pixel_XL_API_30_AOSP Android version: 11 Test-runner (select one): jest-circus

And will iterate depending on how long of a timeout is set in the DetoxTest.java file....The application is open and sitting on the welcome page. It's interactive and seems to be working fine. Navigating to different pages and triggering actions doesn't seem to snap detox out of it's funk - quite frustrating! There don't appear to be any visible animations, but I am not sure how to identify what aspect of the application is causing this interaction with the 'DYNAMIC_TASKS_HAVE_IDLED' parameter.

What's strange is that eventually it will timeout and "fail", but the error captured during the app initialization won't trigger a failure until you enter the first test (using Jest). We run a 'beforeAll()' block prior to each test to spin up user data, login, etc., and we rerun device.launchapp() prior to each test. The second time we launch the app, it seems to work just fine! I can continue to load more instructions into the 'beforeAll()' block and move forward with automation. If I could clear that initial error from the device object, it seems like that tests would go ahead no problem!

Would disabling synchronization on the first boot, adding some sleep, and then re-enabling it on the second device.launchApp() command be a plausible workaround?

I'm also curious if this could be due to poor configuration, poor build scripts/files, etc... I am relatively inexperienced, and especially inexperienced with Android.

I am going to look into adding Test Butler next - hopeful that this might help with such an issue from some of the documentation.

Thanks!

[adrienharnay]

Seeing the same issue today on iOS, with a network request.

The event "Network Request" is taking place with object: "URL: “https:***"

device.launchApp() never resolves. { detoxEnableSynchronization: 0 } doesn't work either.

[d4vidi]

@jonathanmos isn't this a dup of #3461? If so, please close

[jonathanmos]

Fixed in #3503