In Cypress, why is a jQuery element captured in .then() unsafe after an action?

## What `.then()` hands you `cy.get('[data-cy=room-row]').first().then(($row) => { … })` calls your callback once with a jQuery wrapper around the element as it was at that moment. Two properties of that wrapper matter: - **It is a snapshot.** It holds one specific node. It is not a live selector and it does not re-resolve. - **The callback is not retried.** Cypress runs it once and moves on, so nothing ever refreshes `$row` for you. The Cypress documentation makes the point directly: wrapping several actions in a `.then()` "does not protect against detached DOM errors any better than direct chaining", and the captured element "becomes stale" once the DOM updates. So the moment anything inside or after that callback causes the room list to re-render — confirming a booking, changing the check-in date, a price refresh landing — `$row` refers to a node that has left the document. ## Why this is worse than the error A detached-subject error is loud. This is quiet. A node removed from the document keeps its children, attributes and text, so ordinary jQuery reads against it still succeed and still return values: - `$row.text()` returns the text the row had **when it was captured**, not what the page shows now. - `$row.hasClass('is-booked')` reports the class list of the dead node. - `$row.find('[data-cy=nightly-rate]').text()` walks the detached subtree happily. Every one of those can make an assertion pass while describing a row nobody can see. A test that books the Deluxe King room and then asserts `expect($row.text()).to.contain('Deluxe King')` proves only that the string you captured before the click still says what it said before the click. Feeding the stale element back through Cypress catches *some* of this. `cy.wrap($row).should('have.text', …)` runs the attached guard and throws the detached error. But the guard is skipped for existence and `have.length` assertions, so `cy.wrap($row).should('not.exist')` passes against a detached node — the assertion is satisfied by the very staleness you were trying to rule out. ## The shape that works The rule is to carry **values** out of a callback and **queries** across an action, never elements. 1. **Read what you need inside the callback and keep the primitive.** Pull the rate out as a string or a number; the string does not go stale. 2. **Start the next step with a query.** `cy.get('[data-cy=room-row]').contains('Deluxe King')` after the action resolves against the page as it is now, whatever the framework replaced. 3. **Alias when the row is hard to name.** `.as('deluxeRow')` and re-reading the alias re-runs the query for you rather than pinning the element. 4. **Do not wrap several actions in one callback to "keep" the element.** Separate statements are both simpler and safer, because each one queries again before it acts. ## What this looks like in review | pattern | verdict | |---|---| | `.then(($row) => { const rate = $row.text() })`, then query again | fine — a string crossed the boundary | | `.then(($row) => { cy.wrap($row).click(); cy.wrap($row).should(…) })` | the wrap does not refresh anything; the second step is holding a dead node | | `$row` stored in a `let` outside the callback and used in a later `it` | the node is from a previous page state and almost certainly detached | | `cy.wrap($row).should('not.exist')` used as a "did it go away" check | passes for a detached node, so it cannot distinguish removed from replaced | ## How to spot it in a suite that is already green The symptom is not a failure, so you cannot wait for CI to find it. What you look for instead: - **An assertion whose expected value came from before the action.** If a test reads a rate, books the room, and then asserts on the rate it read, it is asserting that a string equals itself. - **A check that would pass if the feature were deleted.** Take the behaviour away and re-run the test in your head. If a captured element still answers the assertion, the test proves nothing about the page. - **A `.then()` callback that contains an action.** The callback is where a snapshot and an action can meet, and it is the shape worth reviewing first. - **A jQuery element in a variable outside a callback.** Once it outlives the statement that created it, it is holding a node from an earlier page state and almost certainly a detached one. None of these needs tooling to find; they are grep-and-read reviews. The payoff is disproportionate, because a test in this shape is worse than no test — it occupies the slot where real coverage would be, and it reports green while the booking flow it names goes unchecked.