When filtering get() with additional commands, the retry should happen on the get() call

[johnnysprinkles]

Current behavior:

Chained query selectors only retry the last one before the assertion, as discussed in #1210 this is desired behavior. But this makes .eq() useless.

Desired behavior:

We'd have a way to group together chained commands, where the commands all deal with DOM querying, into an atomic retry chain.

This code fails:

cy.get('#mytable tr').eq(5).should('not contain', 'blah');

While this code succeeds:

cy.get(`#mytable tr:nth-child(${5 + 1})`).should('not contain', 'blah');

Retrying the .eq() call makes no sense because the DOM selection set is already set and fixed. You can retry .eq() until the sun goes down and the result never changes.

I can think of a couple ways to change to API allow for this. Maybe we could extend the options parameter to get() to include filters or something, so you could have code like:

cy.get('#mytable tr', { filters: [ x => x.get(5) ] }).should('not contain', 'blah');

Or a new "connector" command that explicitly says to retry at the start of the group, something like:

cy.get('#mytable tr').also(x => x.get(5)).should('not contain', 'blah');

But really, for these DOM filtering operations like last() and eq(), why would anybody not want the retry to happen on the get() call? Can we at least leave a bug open for tracking this issue.

Test code to reproduce

See above.

cy.get('#mytable tr').eq(5).should('not contain', 'blah');

vs

cy.get(`#mytable tr:nth-child(${5 + 1})`).should('not contain', 'blah');

Versions

Cypress 3.8.1, MacOS

[jennifer-shehane]

Duplicate of #3561