Detox: device.enableSynchronization() doesn't work and messing with the other tests

Description

In some of my test cases, I have to disable auto synchronisation and wait for an element manually by waitFor API.

I have tested this issue on the latest Detox release and it still reproduces

Reproduction

describe("my test suite", async () => {
     it("needs to handle synchronisation manually", async () => {
        await device.disableSynchronization();
        // Doing some stuff
        await waitFor(element(by.id("myElement"))).toBeVisible()
         
        await device.enableSynchronization();
     })

     it("needs to handle synchronisation automatically", async () => {
        // All my tests here is failing because auto synchronisation is disabled ⛔ 
     })
})

But if I relaunch the app, it works.

describe("my test suite", async () => {
     it("needs to handle synchronisation manually", async () => {
        await device.disableSynchronization();
        // Doing some stuff
        await waitFor(element(by.id("myElement"))).toBeVisible()
         
        await device.launch({ newInstance: true });
     })

     it("needs to handle synchronisation automatically", async () => {
        // Everything is fine here ✅ 
     })
})

Expected behavior

The await device.enableSynchronization(); should work as expected and prevent messing with the other test cases.

Environment (please complete the following information):

Detox: 18.2.2
React Native: 0.63.2
Node: 15.5.1
Device: Simulator iPhone 11Pro
Xcode: 12.4
iOS: 14.4
macOS: 11.1

Logs

If you are experiencing a timeout in your test

I have followed the instructions under Identifying which synchronization mechanism causes us to wait too much, I have read synchronization debug documentation and am providing the relevant synchronization debug output below:

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 4
Comments: 17 (3 by maintainers)

Commits related to this issue

Improve sync enable/disable API doc (warn about suspension, ref: #2630) [ci skip] — committed to wix/Detox by d4vidi 3 years ago

Most upvoted comments

@dani-mp Looking at the example project, seems that the very call to device.enableSynchronization() triggers a wait until the app goes idle. This is what’s blocking your tests – not the various assertions. Whether that’s good practice or not, is definitely something to discuss internally. We will “take it offline” and think that through (namely, whether enableSynchronization() should just enable and return). You are more than welcome to solicit your opinion! 🙏🏻

In any case, we value your patience and work a great deal!

d4vidi on May 2, 2021

@d4vidi thanks, folks, for the update and clarifying it on the docs!

dani-mp on May 17, 2021

Disabling sync does not do that in all running instances, period. This is not the direction towards solving this issue…

d4vidi on Feb 15, 2021

@hamidhadi I tried to reproduce but the issue does not reproduce for me.
await device.enableSynchronization() works as expected in the example I tried. Provide a demo project were a test (another it) is failing after the sequence of disable/enable synchronization

alon-ha on Feb 11, 2021

@d4vidi yup, we’re now aware of this. I think the sample provided respects this, it’s just the original description of the issue what is wrong.

dani-mp on Apr 4, 2021

@d4vidi enjoy your holiday!

We did use Detox 17 and I believe we had the same issue, but I’m not 100 % sure. Then we transitioned to 18 to see if it was fixing it. We went back to 17 for some time because of some problems we had in CI (some extra flakiness), but we understood that it wasn’t caused by the version and moved back to 18.

dani-mp on Apr 1, 2021

@denissb Hey! I work w/ @hamidhadi. Yes, we’re running tests in parallel. What you say makes sense, but I guess the ideal would be that disabling sync only does it for a concrete instance. We make sure that we disable sync at the last moment possible and enable it again afterward, but we can’t run that test with sync enabled right now, and losing the power of --workers 2 wouldn’t be great either.

Let’s see if @alon-ha has any ideas!

dani-mp on Feb 15, 2021

@alon-ha Please take a look.

LeoNatan on Feb 7, 2021