Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cypress wait is displaying nondeterministic behavior #2387

Closed
allisondhall opened this issue Aug 22, 2018 · 4 comments
Closed

Cypress wait is displaying nondeterministic behavior #2387

allisondhall opened this issue Aug 22, 2018 · 4 comments
Labels
type: duplicate This issue or pull request already exists

Comments

@allisondhall
Copy link

allisondhall commented Aug 22, 2018

Is this a Feature or Bug?

Bug

Current behavior:

I am calling cy.wait('@alias') and sometimes it fails to detect that the aliased API call has been triggered when it has actually been called. It will work about 80% of the time, but about 20% of the time my wait will timeout with a failure. I have seen this on several of my endpoints and have yet to determine if it is exclusive to second calls on aliased endpoints or not. Here is an example of a situation where a failure occurred.

I have an alias called @plans. In the below screenshot, you can see a wait called on line 11 and it successfully finds the method. If you look at the bottom of the screenshot you will see another wait for plans. This one however ended up failing despite the XHR call to plans. My page is also updated properly from a successful plans call.

screen shot 2018-08-22 at 2 33 50 pm

Here is a trimmed down version of my test with the alias:

beforeEach(() => {
    cy.server();
    cy.route({
      method: 'GET',
      url: '/api/v1/schools/*/**'
    }).as('plans');
});

it('should allow users to edit plans', () => {
    const seed = `cypress-plans-${Cypress.env('E2E_SEED')}`;
    cy.signIn(seed);
    cy.visit('/billing/plans');
    cy.wait('@plans');

   // Do some cy.get() calls and change plan items

    cy.contains('Save Changes').click();
    cy.wait('@plans'); // This is the line that fails
    cy.get('table tbody > :first-child > :nth-child(4)').should('to.have.text', '$50.50');
    cy.screenshot();
  });

Here is a screenshot when things go as planned:
screen shot 2018-08-22 at 2 49 52 pm

This may or may not be useful, but I tend to see this issue on back to back API calls. For example, in the case above an edit call is made before the plans call. When I've tried waiting for both calls to occur (which would be my preferred state) the error happens more frequently. I see the issue when the runner seems to make calls extra fast. Not scientific at all, but maybe something to go off of. My hunch here is that the wait does not start listening until after the API call has been successfully made.

Desired behavior:

I would expect cy.wait('@alias') to perform consistently and to not timeout when my API call has been made.

Steps to reproduce:

Repo: https://github.com/allisondhall/cypress-test-tiny - I haven't been able to get an isolated reproduction but here is the repo I'm working on it in.

General:

  1. Set up Cypress tests with an aliased API call
  2. Trigger multiple calls to that endpoint and call cy.wait() for each one
  3. Run the test as least 10 times or until a failure is seen.

Versions

Cypress: 3.1.0; MacOS High Sierra 10.13.5; Electron 59

@jennifer-shehane jennifer-shehane added the stage: needs investigating Someone from Cypress needs to look at this label Aug 28, 2018
@bobbyrenwick
Copy link

I am experiencing the same issue at maybe a 50/50 ratio and it's a real blocker to actually using cypress in our CI process.

screen shot 2018-09-17 at 14 02 05

Because I have am contacting a graphql endpoint I've done the window.fetch = null hack to make XHR stubbing work and I've written a custom command (below) to wait for a particular type of request to be responded to, or else wait again, as demonstrated below.

The first XHR in the screenshot is one that passes the test, but it's almost as though the XHR is returning before the waiting begins, or something.

function waitForMutation() {
    cy.wait("@graphql").then(({ request }) => {
        // We might hit a polling graphql
        if (!request.body.query.includes("mutation")) {
            waitForMutation();
        }
    });
}

Cypress.Commands.add("waitForMutation", waitForMutation);

Versions
Cypress: 3.10; MacOS High Sierra 10.13.6; Chrome 69

@CliffDavis
Copy link

CliffDavis commented Sep 21, 2018

As part of migrating from v3.0.0 to v3.1.0, I began experiencing issues where subsequent wait blocks would treat previously satisfied items as satisfied for the remainder of the test.

it('Adds, edits, and deletes an item from the overview page', () => {
      cy.get('[data-test-id="realEstate"]').click();
      cy.wait(['@getRealEstate', '@getProperty', '@getBusiness']); // Properly waits for all calls to resolve

      // snip: creation logic...

      cy.get('.SubmitButton').click();
      cy.wait(['@createRealEstate', '@getRealEstate']); // this block will continue as soon as @createRealEstate is resolved

      // ...
});

edit for clarification:
further experimentation showed that each occurance of the aliased call required an associated cy.wait(), otherwise previous resolved calls would satisfy wait commands further on in the test

ie: due to the page refreshing, the calls occur twice after the wait at command 7, the second calls cause the wait at command 15 to pass before the page has fully reloaded
image

adding an unnecessary cy.wait() as command 11 brings the resolved/wait count in parity and properly controls flow of the test
image

Desired Behavior
a cy.wait() should only be satisfied by an XHR that is a result of the preceding chained action, or a command should exist to flush the queue of resolved requests to ensure waits are only triggered by new requests.

Versions
Cypress: 3.10; MacOS High Sierra 10.13.6; Electron 59

@jlmart88
Copy link

This is likely a duplicate of #2227, which contains a link to an repo with this behavior being demonstrated:
#2227 (comment)

@jennifer-shehane
Copy link
Member

Duplicate of #2227

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

5 participants