Cypress Test Runner and Browser Under Test: cy.intercept stub timing vs assertion retry

Cypress runs tests inside a real browser and proxies network traffic between the test runner process and the application under test. The integration boundary is relevant when verification of UI state depends on network interception via cy.intercept.

The goal is to understand how stubbing, delaying, or asserting on network calls interacts with Cypress assertion retry behavior. Assertions automatically retry until timeout, which changes verification of dynamic UI compared to one-shot checks. Backup creation, restoration, or data recovery are not Cypress capabilities and are out of scope for this integration.

Uncertainty remains about the ordering guarantees between intercept registration and the first request, and how retry interacts with intercept lifecycle across e2e and component testing modes. Version-sensitive changes to interception APIs add further ambiguity.

Does an assertion that depends on a stubbed response wait for the intercept to be registered, or can it succeed on a prior real response? Under what conditions does automatic retry allow a test to pass with stale network data when intercept timing shifts? Is retry behavior consistent between e2e and component testing for intercepted requests?