Add support for waiting on the Nth request/response in cy.intercept()

[flotwig]

Current behavior:

cy.route has (undocumented) support for waiting on the Nth request/response:

cy.wait('@foo.1') // first response
cy.wait('@foo.request.1') // first request
cy.wait('@foo.response.5') // fifth response

cy.route2 does not have this.

Desired behavior:

Implement this in cy.route2, so that the following tests can pass:

cypress/packages/driver/test/cypress/integration/commands/net_stubbing_spec.ts

Lines 991 to 1030 in 1b472e0

	context.skip('indexed aliases', function () {
	it('can wait for things that do not make sense but are technically true', function () {
	cy.route2('/foo')
	.as('foo.bar')
	.then(() => {
	$.get('/foo')
	})
	.wait('@foo.bar.1')
	.wait('@foo.bar.1') // still only asserting on the 1st response
	.wait('@foo.bar.request') // now waiting for the next request
	})
	it('can wait on the 3rd request using "alias.3"', function () {
	cy.route2('/foo')
	.as('foo.bar')
	.then(() => {
	_.times(3, () => {
	$.get('/foo')
	})
	})
	.wait('@foo.bar.3')
	})
	it('can timeout waiting on the 3rd request using "alias.3"', function (done) {
	cy.on('fail', (err) => {
	expect(err.message).to.contain('No response ever occurred.')
	done()
	})
	cy.route2('/foo')
	.as('foo.bar')
	.then(() => {
	_.times(2, () => {
	$.get('/foo')
	})
	})
	.wait('@foo.bar.3', { timeout: 100 })
	})
	})

Depends on #687

[flotwig]

Existing discussions on this behavior:

• [WIP] Enable aliases names to contain the dot character #3929 (comment)
• Document @alias.all and @alias.2 cypress-documentation#1573

[quad5]

Hi, #687 is now closed. Any chance to get this enhancement ticket on to the implementation queue. This enhancement would help with the issue I reported (#9034). Thanks.

[vojta-k]

Hi! This feature could potentially resolve our issue #14703 - !! if it would also include the possibility to select not just a specific n-th call from the start, but also the LAST one (e.g. by passing n=-1)

[vala84no]

The ability to get the last one seems likely to cause subtle bugs. How do you know there isn't another request about to come through and how do you know that one isn't the one the developer wanted? Unless you can guarantee that the request you want has already happened you can't feasible get the "last" request and know its what you're after. It seems extremely likely that people will use that incorrectly. At least Nth request is far more likely to be deterministic.

[mohamedatef2020]

@thor84no I believe waiting on the last request is the more realistic scenario.
If I'm on a page with an api that returns a list of element and I'm performing filtering/sorting action I will send multiple api calls to same endpoint with different parameters but I'll always need to wait on the last sent request to assert the displayed data after performing any of the actions.

It would be like:

cy.intercept("**list/).as("list")
getListRequest()
cy.wait(@list).then(assertDefaultData())
sortListAction()
cy.wait(@list).then(AssertSortedData())
filterListAction()
cy.wait(@list).then(assertFilteredData())

[vala84no]

@mohamedatef2020 but how could Cypress possibly know that it's actually the last request? It can't. You have to tell it how many requests there will be and it then has to wait for the nth request. At any given moment the most recent request is the last request with a possibility of a "last" request coming soon. That never changes.

If you look at what I responded to that post suggested using -1 as an indication that we should wait for whatever is the last request. That has nothing in common with your example code which is effectively wait for the 1st request, then the 2nd, etc.

I.e. your example is repeatedly wait for one more request, not wait for the last request.

[mohamedatef2020]

@thor84no I agree with you on that. I meant to mention latest request not last.
For now cy.wait() only returns the first request no matter how many requests where sent inside the test and how many times I wrote cy.wait() in my code. all of them will refer to the first matched request not the latest!