Clearing previously intercepted routes

What would you like?

I’d like to be able to clear previously intercepted routes so that waiting on an aliased intercept will now start from the next interception.

Example:

describe('Interceptions', () => {
  it('Resets interceptions', () => {
    cy.intercept('GET', '/foo').as('foo')

    cy.wait('@foo') // request #1 to /foo

    // Get some variable to see current state

    // request #2 to #n to /foo // there could potentially be more requests, too

    cy.get('button').click()

    cy.resetIntercepts('@foo') // would like to have something like this so that request #2 to #n will be forgotten about

    // request #n+1 to /foo

    cy.wait('@foo') // will yield request #n+1
  })
})

Why is this needed?

If the number of requests is unknown beforehand, using cy.wait() on the same alias is not useful.

For example, I have a request that is called every X seconds, and I want to compare the state after taking some action. There may or may not have been one or more requests between:

1. the first request where I record the state that I know won’t change by the time the action is taken, and
2. the request after the action was taken

I cannot rely on cy.wait() being called two times, or three times, etc.

Currently I do the following:

describe('Interceptions', () => {
  it('Uses the correct request', () => {
    cy.intercept('GET', '/foo').as('foo')

    cy.wait('@foo') // request #1 to /foo

    // Get some variable to see current state

    // request #2 to #n to /foo

    cy.get('button').click()

    cy.intercept('GET', '/foo').as('bar') // intercept same request, but use a different alias to reference new interceptions without needing to wait on the previous ones

    // request #n+1 to /foo

    cy.wait('@bar') // will yield request #n+1, but with more complex arguments to cy.intercept could be annoying
  })
})

But, as noted, it’s not ideal to created a new cy.intercept() call and alias for really the same intercept.

Other

#23190 - discussion on the same point

[ezrag26]

If I un-comment the Wait A, then it works fine and the Wait B waits for the requests made by Trigger 2. This seems to mean that cy. wait relies on the order of the requests (Trigger 1 >> Wait B) and not on the order of the code/events (Trigger 2 >> Wait B).

I couldn’t find the behavior documented in the docs. If that is right, it would be nice to have it documented.

I do believe it’s documented here regarding cy.wait(), where it says:

Each time we use cy.wait() for an alias, Cypress waits for the next nth matching request.

So if there were 5 requests matched, no matter when the the 1st use of cy.wait() is made, it will wait on the 1st matched request to finish, the 2nd use on the 2nd matched request, etc. And if the nth request already finished before that nth use of cy.wait(), the code will immediately continue.

It seems that in your case you may have a more determinate behavior where you can wait on that first matched request (albeit it do nothing) as you know there will be just 1 before Trigger 2, while for me the number of matched requests will be unknown. But I do agree that our cases are both similar in that we don’t care about the previous interceptions up until some specific trigger, and adding a feature like this would certainly seem to be useful.

[emilyrohrbough]

@piotrpalek You are referring to https://github.com/cypress-io/cypress/issues/20397.

The ask in this issue is to clear intercepts mid-test and/or provide a way to verify the intercept call out to verify the requests/responses.