should chained indirectly to wait does retry

[gofr]

Current behavior

The documentation for wait states:

cy.wait() will only run assertions you have chained once, and will not retry .

That's great, because intercepted requests (for example) don't change, so retrying wouldn't be useful. And that description is accurate if the should is chained directly to the wait, like this:

cy.wait('@err').should('have.property', 'error')

But the documentation also contains a lot of examples that do something like this:

cy.wait('@someRoute').its('request.body').should('include', 'user')

In this case, the should is chained to the its and does retry.

Desired behavior

I know it's possible to work around this. I can add { timeout: 0 } to the its command. But ideally, Cypress would be able to figure out that it's still in a "wait chain" and still wouldn't retry. (Does it ever make sense for commands further down such a chain to need retrying?)

Alternatively, the documentation should be clarified to explain how this works, and perhaps the examples should be updated to include { timeout: 0 } in all such cases, so tests aren't slower than they need to be.

Test code to reproduce

A test like this in the cypress-test-tiny repo will fail (as expected). But it will not fail immediately. It will only fail after pointlessly retrying for 4 seconds (the default timeout):

it('is slow', () => {
  cy.intercept('/').as('page');
  cy.visit('https://example.cypress.io');
  cy.wait('@page').its('response.statusCode').should('eq', 500);
});

Cypress Version

10.9.0

Node version

16.14.2

Operating System

not relevant

Debug Logs

No response

Other

No response

[warrensplayer]

Reproduction following examples above is here: warrensplayer/cypress-test-tiny#1

[warrensplayer]

@gofr Thanks for reporting this. The functionality definitely does not align with the documentation. We will take a closer look at this.

[steinybot]

Current behavior
The documentation for wait states:

cy.wait() will only run assertions you have chained once, and will not retry .

That's great, because intercepted requests (for example) don't change, so retrying wouldn't be useful.

I completely disagree with this. wait automatically increments so retrying would be extremely useful (I can't get it to work).

In my case I intercept every request and check if it is a graphQL request and if it is I pull out the mutation name and alias the request using that. Then in my tests I can, with no extra setup, wait for a particular mutation. What I also want to do is wait for certain mutations and then if that mutation contains a particular value I will proceed. For example we have an auto save feature on our forms which has a bunch of debouncing etc. This means that the number of requests that actually get sent are not relevant, I just need to wait until a particular mutation with the field I care about gets saved. In this specific test I am checking that I can resume from an autosaved state. If I don't wait then I can't tell if I am resuming before or after the autosave I am interested in occurred. If I had to wait for a certain number of requests to occur then the test would be overspecified and extremely brittle (if the number is even deterministic). I'm going to have to duplicate my interception logic within each test and give it some other unique alias.

Wait should definitely retry.