Why is the response callback not always ran during cy.wait(@)?

[TjeuKayim]

This is about an app that runs setTimeout while processing the HTTP response. Even though the test uses cy.intercept().as(.. and cy.wait("@.., it still does not reliably call the cy.tick() after the fetch().then() callback. Both in Firefox and Edge, this test is flaky (fails 30% of the time), and it gets worse when enabling network throttling in dev tools. After I added logging, I noticed that the callback sometimes executed after cy.wait("@, while I expected Cypress to wait until the HTTP response was processed before executing the next commands after wait().

What am I doing wrong?

The app code:

fetch('/foobar').then((response) => response.json()).then(() => {
    console.log('got response', new Date().toISOString())
    setTimeout(function() {
        console.log('modifying h1', new Date().toISOString())
        document.getElementById('foo').textContent ='Bar'
    }, 200)
})

And the test:

cy.clock(null, ['setTimeout']);
cy.intercept("foobar*", { body: {} }).as("fetch");
cy.visit("http://localhost:8080/bug");
cy.tick(500);
cy.wait("@fetch");
cy.tick(500);
cy.log().then(() => console.log('going to assert', new Date().toISOString()))
cy.get("#foo").contains("Bar");

Console logs:

Example failure:
  ==== test 1 ==== 2022-12-29T14:47:43.305Z
  going to assert 2022-12-29T14:47:43.400Z
  got response 2022-12-29T14:47:43.406Z

Example success:
  ==== test 2 ==== 2022-12-29T14:47:47.514Z
  got response 2022-12-29T14:47:47.582Z
  modifying h1 2022-12-29T14:47:47.591Z
  going to assert 2022-12-29T14:47:47.596Z

See this repository to reproduce TjeuKayim/cypress-example-kitchensink@9c6a4ae

[TjeuKayim]

After some more testing, I found that other unrelated HTTP requests (for example loading images) are influencing whether the response callback is executed before or after the cy.wait(@... I could also reproduce a case where enabling network throttling actually improves the success rate of the tests significantly because the other network activity somehow influences the order (while throttling often makes tests fail).

Does Cypress have a feature like cy.waitForNetworkResponsesAndDomToSettle() that I could add after the call to cy.wait()?

[TjeuKayim]

Thanks for the idea. Replacing the cy.wait('@fetch') with cy.waitForNetworkIdle('foobar*', 1500) makes the test less flaky: with dev tools network throttling 'Fast 3G' the test passed 40 / 40 times, however with 'Slow 3G' it still fails all the time. I see cypress-network-idle uses req.on('response' under the hood. With dev tools network throttling 'Slow 3G', the after:response event can fire more than a second before the callback runs console.log('got response... As the plugin does not actually wait until the callbacks have run, it is no better than doing cy.wait('@fetch'); cy.wait(1500). And I would like to avoid the anti-pattern of arbitrary waits.

[Prashant-Kan]

I want to setup / preconfigured the Throttling speed of Browser(Chrome) when my cypress test gets start.
I want to test my functionality in Slow 3G.

Is there any way to launch my browser with Slow 3G in some case and in rest of the case it should launch with Fast 3G or No throttling ?

[TjeuKayim]

Does the following answer your question about automatically configuring throttling?

You can throttle your network connection by accessing your Developer Tools Network panel. Additionally, you can add your own custom presets by selecting Custom > Add from the Network Conditions drawer.
We do not currently offer any options to simulate this during cypress run.
https://docs.cypress.io/faq/questions/using-cypress-faq#Can-I-throttle-network-speeds-using-Cypress

[TjeuKayim]

The workaround that I ended up with is to spy something that runs during the HTTP response handling, and wait for it to be called.:

Cypress.Commands.add("tickAndWaitForCallback", () => {
  let spySetTimeout;
  cy.window().then((win) => (spySetTimeout = cy.spy(win, "setTimeout")));

  cy.tick(200);

  cy.get().should(() => {
    expect(spySetTimeout).to.be.calledWithMatch(Cypress.sinon.match.func, 200);
    spySetTimeout.restore();
  });
});

In case the HTTP response handler alters something in the DOM, you could also wait for that change. In some cases, it was easier for me to spy on the setTimeout function.

Since this solution, the cypress tests cases became reliable, even with much CPU and network throttling.

[Prashant-Kan]

Appreciated on your quick response.

Sorry, Didn't get your workaround which could make the network call in Slow3G speed. :(

was looking to pass some config command during browser launch So, that in network tab it shows Slow3G as selected option for throttling.

Can you explore on this to achieve my target.
i have used cy.intercept and cy.wait as soon as my server calls gets triggered. It works well
Just want to test by decreasing the network speed during particular testcase. Even though my network speed is Fast.