cypress v16: cy.intercept() freezes the command queue

[asirvadAbrahamVarghese]

After cy.visit() navigates to a Rails application, calling cy.intercept() causes the Cypress command queue to freeze permanently. No subsequent commands execute - no clicks, no waits, no assertions.

it('reproduces the freeze', () => {
  cy.visit('http://localhost:3000/actions')   // navigates fine
  cy.intercept('POST', '/actions/select_node**').as('selectNode')  // ← queue freezes here
  cy.get('button.submit').click()  // never executes
  cy.get('body')   // never executes
  cy.wait('@selectNode')  // never executes
})

The freeze happens at the cy.intercept() command itself in the queue. All commands before it run normally. The route is registered (visible in the Cypress Routes panel), but the queue never advances past the intercept call.

But it worked fine with v15. In v16, it also works fine on Electron and with forceHttp1: true

[DYNOSuprovo]

The freeze occurs due to a race condition between Cypress's command queue and the HTTP/2 proxy stream synchronization in Chromium when routes are defined after navigation.

1. Root Cause

In Cypress v16, the network interception layer in Chromium was reworked around Chrome DevTools Protocol (CDP) Fetch/Network domains with full HTTP/2 stream multiplexing.

When you call cy.visit() first on a Rails application, the browser loads the page and opens persistent HTTP/2 connections (often kept open by Rails/Puma for assets, Turbo Drive, or ActionCable/SSE).

When cy.intercept() is invoked after the page has already completed loading:

1. The Cypress proxy attempts to dynamically attach the intercept handler and reconfigure route listeners across the active, multiplexed HTTP/2 connection pool.
2. In Chromium, the CDP network synchronization stalls waiting for the active HTTP/2 streams to drain or settle, which prevents the Cypress command queue promise from resolving.
3. This is why:
   • forceHttp1: true works: HTTP/1.1 uses discrete connections rather than multiplexed streams, so the proxy handler attaches synchronously without waiting on active stream multiplexers.
   • Electron works: Electron runs an embedded Chromium environment with distinct network socket lifecycle management compared to external Chrome.

---

2. The Solution: Declare cy.intercept() Before cy.visit()

The official Cypress best practice is to always define network interceptors before the action or navigation that might trigger requests:

it('executes smoothly without freezing', () => {
  // 1. Declare the intercept BEFORE visiting the page
  cy.intercept('POST', '/actions/select_node**').as('selectNode')

  // 2. Visit the page
  cy.visit('http://localhost:3000/actions')

  // 3. Perform actions
  cy.get('button.submit').click()

  // 4. Assert / wait on the intercepted request
  cy.wait('@selectNode')
})

By declaring cy.intercept() before cy.visit(), Cypress registers the route pattern in the proxy before any HTTP/2 connection or CDP session is negotiated with your Rails server, completely avoiding the post-navigation stream attachment freeze.

---

3. If you must keep HTTP/1 fallback for Rails / Puma

If you have tests where routes dynamically generate during page execution and Rails keeps streaming connections open, configuring forceHttp1: true in your cypress.config.js is the officially supported workaround:

// cypress.config.js
const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    // Forces HTTP/1.1 proxying to avoid HTTP/2 stream multiplexer stalls with Rails/Puma
    forceHttp1: true,
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
})

Moving cy.intercept() before cy.visit() should resolve the freeze immediately! If this resolves your issue, feel free to mark this as the accepted answer.

[asirvadAbrahamVarghese]

Yeah, totally makes sense what you said.

2. I had also already tried cy.intercept before cy.visit, but cy.wait still fails with “No request ever occurred,” so Cypress seems completely unaware of these calls and can’t wait for them at all. Either way, the behavior still feels pretty buggy to me.
3. I didn’t want to go with forceHttp1 since that option was deprecated with v16 itself.

[muhammadmobi]

This looks like a Cypress 16 regression on the new default network path for Chrome, not a problem in your test. For now, keep forceHttp1: true (or run in Electron), and report it with a reproduction.

Why Electron and forceHttp1 both work

Cypress 16.0.0 made a CDP-based "browser network path" the default for Chrome, Chromium and Edge. Electron, Firefox and WebKit stay on the old HTTP/1 proxy, and forceHttp1: true puts Chrome back on that proxy (#34633). So the two setups that work for you are exactly the two that avoid the new path.

Where it's stuck

cy.intercept() registers the route in the browser first, which is why it shows up in the Routes panel. Then it waits for the Cypress server to confirm the route (add-command.ts#L239 → Cypress.backend('net', 'route:added', …) in events/index.ts). That wait has no timeout, so if the reply never arrives, the queue hangs forever instead of failing. On the server, adding a route only pushes it onto a list, and it's the same code on both network paths (driver-events.ts#L22-L40). So the stall is in the browser ↔ Cypress server round trip after your Rails page loads, not in your route or matcher.

What to do

1. Keep the workaround for now. forceHttp1 is already marked deprecated and prints a warning, so treat it as temporary:

   // cypress.config.js
   const { defineConfig } = require('cypress')
   
   module.exports = defineConfig({
     forceHttp1: true, // temporary: cy.intercept() hangs on the Cypress 16 browser network path
     e2e: {
       // ...
     },
   })

2. Try registering the intercept before cy.visit(). The cy.intercept() docs recommend that order anyway. It also tells you whether only calls made after the Rails page loads hang. It may not avoid the bug, but it's a quick check.

3. Open an issue with a debug log. It's what the team needs to fix this:

   DEBUG=cypress:net-stubbing*,cypress:server:socket-base npx cypress run --browser chrome --spec cypress/e2e/your-spec.cy.js

   Look for received driver event with route:added. If it's in the log, the server got the route and the reply back to the browser is what's lost. If it isn't, the request never reached the server. Also say whether the page opens a WebSocket (ActionCable, Turbo Streams) or registers a service worker. The new path still has open issues around service workers (for example #34674).

[muhammadmobi]

Thanks for confirming, and for ruling out service workers. That makes it look like the issue is in Cypress, not in Rails or ActionCable. On Chrome, Cypress.backend calls (like route:added) don't go over HTTP. The runner's socket uses a CDP binding (browser.ts#L39-L43, cdp-browser.ts#L77). So "never reached the server" means Cypress's CDP channel for that tab stopped delivering after the visit.

Two issues opened yesterday show the same pattern: Chrome native network only, it starts right after cy.visit(), and forceHttp1: true fixes it:

• #34968: after cy.visit() every cy.task() times out, and the runner's /__cypress/add-verified-command request is answered by the app's own server (404).
• #34969: CDP Fetch.* commands stop resolving mid-run, and after that the server logs no more socket messages.

Two quick checks would show whether #34964 belongs with them:

1. Add a no-op task (on('task', { ping: () => null })) and call cy.task('ping') right after cy.visit(), in place of the intercept. If that hangs too, it's the Cypress 16 Chrome native network: after cy.visit(), /__cypress/add-verified-command reaches the app server (404) and every cy.task() times out; forceHttp1: true avoids it #34968 pattern, not something specific to cy.intercept. Also check DevTools → Network for any /__cypress/... request that Rails answers with a 404. Cypress's own code notes that's what happens when its Fetch handler fails (serve-internal-routes.ts#L242-L245).
2. Run with DEBUG=cypress:server:browsers:cri-client and look for command Fetch.… has not resolved after 10000ms right after the visit (cri-client.ts#L664). That's the Cypress 16 Chrome native network: CDP Fetch.* commands stop resolving mid-run, cy.visit() hits pageLoadTimeout during cy.session validation and the run hangs; forceHttp1: true avoids it #34969 signature.

If either one shows up, mentioning it in #34964 and linking the other two should help the maintainers treat them as one bug. Until there's a fix, forceHttp1 (or Electron) is still the only workaround, even though it's deprecated. The "No request ever occurred" with the intercept first may be the same stall, but I can't confirm that from the source.

[asirvadAbrahamVarghese]

1. 34968: It looks similar: cy.task hangs when called after cy.visit, but works fine when called before it. One difference I noticed compared to cy.intercept is that Cypress at least fails after a minute with cy.task('ping') timed out after waiting 60000ms, whereas cy.intercept just freezes indefinitely with no further progress
2. command Fetch.… has not resolved doesn’t show up in the logs when running with DEBUG=cypress:server:browsers:cri-client. So I guess this is probably not related to 34969

[muhammadmobi]

Thanks for running both. That puts #34964 with #34968 (cy.task hangs after cy.visit(), works before it, forceHttp1 avoids it) rather than #34969.

The difference you noticed comes from how the two commands handle timeouts, so it doesn't point to a separate bug. cy.task applies its own taskTimeout, so it fails after 60 s (task.ts#L54-L68). cy.intercept just returns the Cypress.backend('net', 'route:added', ...) promise and sets no timeout of its own (add-command.ts#L239, events/index.ts#L49-L56), so when the reply never arrives it just waits.

The maintainers have now asked for a reliable reproduction before they can work on it, so that's the most useful next step:

1. A small public repo that uses your cy.task('ping') probe would be ideal: a minimal Rails (or plain Rack) app plus one spec that pings before and after cy.visit(). If it doesn't reproduce on a bare app, add things from your real app (ActionCable, Turbo, anything that opens a long-lived connection) until it does. That tells them which part triggers it.
2. Post the same probe result on Cypress 16 Chrome native network: after cy.visit(), /__cypress/add-verified-command reaches the app server (404) and every cy.task() times out; forceHttp1: true avoids it #34968 and link cy.intercept() freezes the command queue #34964. Two unrelated apps showing it (Rails here, Express there) makes it easier for them to reproduce than either report alone.

Open PR #34995 (not merged yet) should turn hangs like this into a failure instead of an endless wait in cypress run, but it doesn't fix the stall itself. Until there's a fix, forceHttp1: true (or Electron) is still the only workaround.

[asirvadAbrahamVarghese]

Recreated the issue here. Turns out, when a message sent to Chrome’s DevTools Protocol (CDP) server exceeds limit, the intercept call hangs. See this comment for more details. So in my case, it’s the webpack bundle that’s exceeding the limit.
@muhammadmobi Thanks for helping dig into this!

[muhammadmobi]

Nice find, and thanks for building the repro. There's a related fix in progress: #34794 hits the same 100 MiB CDP limit with a large spec bundle, and open PR #35059 fixes it. Instead of sending the body in one Fetch.fulfillRequest, it lets Chrome load Cypress's internal routes (/__cypress/...) directly, so the body never crosses CDP.

From the PR description, that change only covers Cypress's internal routes. A large body from a cy.intercept stub, as in your repro, would still be sent through Fetch.fulfillRequest (base64, so about 75 MB of content is already over the limit). It's worth pointing that out on #35059 or #34964 with your repro, so the issue isn't closed as fixed by it.

Until then: keep your intercepts from matching the big bundle (a narrower URL pattern), or keep using forceHttp1: true for that spec.

[muhammadmobi]

Following up: your diagnosis was right, and there's now a fix. #35059 was merged on Oct 22 and closes #34794, which is the same problem. After a cy.visit() to another origin, Cypress served the spec bundle again through one CDP Fetch.fulfillRequest. A bundle that ends up over Chrome's 100 MiB DevTools message limit made Chrome drop the connection, so the run hung. Now the browser downloads internal routes like the bundle straight from the Cypress server, so the bundle no longer goes through CDP.

The changelog on develop lists it for 16.2.1, including that forceHttp1: true won't be needed for this anymore. 16.2.1 isn't released yet, so keep forceHttp1 until then.

Your #34964 isn't linked to that PR, so it may be worth commenting there with your repro and a link to #35059. That way it gets closed once you've confirmed it on 16.2.1.

[muhammadmobi]

16.2.1 is out (Oct 28) with the fix from #35059. Its changelog says forceHttp1: true is no longer needed to avoid the hang at the first cross-origin cy.visit() with a large spec bundle (#34794).

Could you try your repro on 16.2.1 without forceHttp1? One caveat from earlier still applies: the fix moves only Cypress's own /__cypress/... routes off CDP. A very large body returned by a cy.intercept() stub still goes through Fetch.fulfillRequest. If your repro stubs a big response and still hangs, it's worth posting that result on #34964.