How far should a Cypress suite go to absorb detached-node failures the app causes?

## Three places the fix can live A detached-node failure can be answered in the test, in the application, or with an escape hatch, and a suite that only ever reaches for one of the three is making a decision by habit. 1. **In the test.** End chains at actions, query again, alias rather than pin, anchor on a container the re-render does not replace. This is ordinary Cypress hygiene and it should be the default for the overwhelming majority of cases. 2. **In the application.** Sometimes the reason no chain survives is that a component is being rebuilt far more often than it needs to be. That is not only a test problem. 3. **With an escape hatch.** `{ force: true }`, a raised `defaultCommandTimeout`, a spec-level retry. These change what you are told, not what happens. ## What each costs | response | what it buys | what it costs | |---|---|---| | re-query and split the chain | correct, local, no coordination needed | more statements; defensive shape in every spec | | a guard assertion before each action | fewer intermittent detachments | every guard is a thing to keep true as the UI changes | | raise it with the app team | may remove the cause for everyone | needs evidence and someone else's time | | `{ force: true }` | the error stops | the event fires at a node not in the document — the test can pass while doing nothing | | a longer timeout | nothing; the subject is fixed | slower failures, and a false belief that timing was the issue | ## Where I put the line - **Absorb the ordinary case without discussion.** A row that is rebuilt when its own data changes is normal framework behaviour. A suite that cannot cope with it has a chain-shape problem, not a product problem, and the fix is a two-line rewrite. - **Escalate when no query can win.** If a region is replaced on an interval, or on every keystroke in the date picker, then no amount of re-querying makes acting on it reliable — and the same churn costs a real user their focus, their scroll position and, for a screen-reader user, a stable reading position. At that point the failing test is evidence about the product, and reporting it is part of the job. - **Escalate when the workaround would hide a defect.** If the only way to keep a test green is to force an action at a node that is not on the page, the test has stopped asserting anything and should fail loudly instead. - **Never let a suppression ship silently.** If a `{ force: true }` genuinely has to go in to unblock a release, it carries a comment naming the reason and a ticket, and someone owns removing it. ## The standard worth writing down Two rules cover almost everything and are cheap to review: - Every action ends its statement; the next step begins with a query or an alias read. - Nothing that crosses an action is an element — only strings, numbers and aliases cross. A suite that follows those two has earned the right to treat a remaining detached-node failure as information about the application rather than as noise to be tuned away. That is the real payoff of the discipline: it turns a class of failure that everyone learns to ignore back into a signal. ## What to bring to the other team Escalating well is a skill, and "your re-rendering breaks our tests" is not it. What makes the case is the frequency and the trigger, stated without reference to the suite: - **How often the region is rebuilt**, and on what — a timer, every keystroke, every response, or only when the data it displays actually changes. - **What a user loses each time** — focus in the guest form, scroll position in a long room list, a half-typed date, a screen reader's place in the page. - **A reproduction that is not a test.** If it can be shown by hand in the browser, the conversation stops being about the test framework. Framed that way, the detached-node failure is the cheapest defect report the team will get that quarter: it arrives with a reproduction, it names the component, and it was found before anyone complained.