A Cypress `cy.intercept()` route with `forceNetworkError` fails the spec with the app's own error. Why?

This failure confuses people because the error message belongs to the application, not to Cypress, so it reads like the test tooling has gone wrong. It has not. The fault you injected worked, and the application had no answer for it. ## The fault is real, not simulated `cy.intercept('GET', '/api/forecast*', { forceNetworkError: true })` destroys the browser connection. From inside the dashboard there is no difference between that and a DNS failure: `fetch()` **rejects** with a `TypeError`, and `XMLHttpRequest` fires its `error` event. Nothing about the rejection is marked as test-generated. If the dashboard's forecast loader has no `catch` — or has one that rethrows, or awaits inside an event handler with no handler above it — the rejection becomes an **unhandled promise rejection** on the application's window. ## Why that ends the spec Cypress executes the spec in the same browser as the application under test and subscribes to the application's error events. Its documented default for the `uncaught:exception` event is to **fail the current test** when an uncaught exception occurs in your application, so the spec fails carrying the app's own message — `TypeError: Failed to fetch`, or whatever the loader threw — and every command queued behind it is skipped, including the assertion on the offline banner. Three details make this readable once you know them: - The event fires with `(err, runnable, promise)`; the third argument is present **only** when the exception originated from an unhandled promise rejection, which is the usual shape for a failed `fetch()`. - The failure is attributed to whichever test was running, even though the code that threw is the application's. - The Command Log still shows the intercepted request in a failed state, with a request snapshot and an error snapshot rather than a response — that entry is the evidence that your route did its job. ## Reading it correctly before you silence it Ask one question before touching any Cypress option: **should the dashboard have survived this?** If the product says the forecast panel shows an offline state when the service is unreachable, then a spec that dies on an unhandled rejection has found a genuine defect. The test is doing exactly what fault injection is for, and the fix belongs in the application, not in the spec. Only when the rejection is genuinely expected — a third-party widget that always throws when offline, a background poller whose failure is deliberately ignored — should the spec suppress it. ## Three ways forward, in order of preference 1. **Add the error path to the application.** The panel catches the rejection and renders its offline state; the spec then passes with no Cypress-side handling at all. 2. **Suppress that one error, narrowly.** Register a handler that returns `false` only for the error you expect, and let everything else keep failing tests: ```js Cypress.on('uncaught:exception', (err, runnable, promise) => { if (promise && err.message.includes('Failed to fetch')) { return false } }) ``` 3. **Scope it to a single test** with `cy.on('uncaught:exception', …)` inside the `it` block, which is unbound automatically when that test ends. Prefer this when only one scenario expects the rejection. What you should not do is put an unconditional `return false` in the support file. That does not make the suite tolerant of injected faults; it makes it blind to every application exception, including the regressions the suite exists to catch. ## Confirming the diagnosis quickly Two pieces of evidence settle it in seconds. First, the failure's message and stack belong to the application's own bundle — a failing Cypress command names the command instead and prints its own explanation. Second, the Command Log entry for the intercepted request sits in a failed state with a request snapshot and an error snapshot rather than a response, and the interception `cy.wait()` would have yielded carries an `error` whose message is `forceNetworkError called` and no `response` property. When both hold, the fault fired as designed and it is the application, not the runner, that stopped the test. ## What the test should assert afterwards Once the rejection is handled, keep the assertions on the application's behaviour rather than on the fault: - the offline or error region is visible and names the failed panel; - the last good forecast, if the product caches one, is still on screen; - a retry affordance exists and is enabled; - unrelated panels — the station list, the alerts feed — still render, because a single failing route should not blank the dashboard. Asserting only `cy.wait('@getForecast').should('have.property', 'error')` proves the fault fired, not that the product handled it. The interception's `error` is worth asserting as a guard, but the user-visible outcome is the point of the test.