Bug
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.

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:

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.
I would expect cy.wait('@alias') to perform consistently and to not timeout when my API call has been made.
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.
Cypress: 3.1.0; MacOS High Sierra 10.13.5; Electron 59
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.

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
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

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

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
This is likely a duplicate of https://github.com/cypress-io/cypress/issues/2227, which contains a link to an repo with this behavior being demonstrated:
https://github.com/cypress-io/cypress/issues/2227#issuecomment-417835581
Duplicate of https://github.com/cypress-io/cypress/issues/2227
Most helpful comment
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.
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 testie: 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

adding an unnecessary

cy.wait()as command 11 brings the resolved/wait count in parity and properly controls flow of the testDesired 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