Set-Cookie from service worker responses does not reach cookie middleware when the proxy is disabled

[AtofStryker]

Part of the proxy-disabled / HTTP/2 pipeline work. Follow-up to #34555 / #34566, raised by Cursor Bugbot in review. Low priority — see Impact.

What & why

With CYPRESS_INTERNAL_DISABLE_PROXY=1, responses fetched on a service worker's CDP session run the middleware onion but arrive with no Set-Cookie, so cookie simulation never applies. Set-Cookie only travels on Network.responseReceivedExtraInfo (#34327), never on a Fetch pause, and CDPNetworkExtraInfo correlates those by ${sessionId}:${requestId} on the page connection — where Network is deliberately not enabled for service_worker targets. So no entry ever exists for a SW-session pause. MITM parity drift: the proxy does see service worker wire fetches.

Impact — why this is low priority

With the proxy disabled there is no server-side cookie jar; the browser is the source of truth. The only consumer of Set-Cookie on that path is simulated-top rewriting — applying cookies as though the AUT were top-level rather than iframed — and a service worker has no document and no top-level browsing context, so that has little meaning for its fetches.

The one case that could matter is a worker handling a document navigation, since that response becomes the AUT document in a frame; instrumenting the driver spec showed 14 such navigations among the 58 SW-session pauses. Nothing regresses by deferring — before #34555, service worker traffic ran no middleware at all.

Do not re-try: awaiting Network.enable deadlocks

CriClient._onAttachedToTarget awaits the onServiceWorkerTargetAttached hook before Runtime.runIfWaitingForDebugger, and CDP does not answer Network.enable on a target still paused for the debugger — so the worker is never released. service-worker.cy.js drops 28/28 → 0 passing on Chrome and Electron, and service_worker_spec.js regresses too. It is the await, not the ordering: Fetch.enable is answered while paused, which is the only reason the current code works. Un-awaited works but lands after the worker starts, so the earliest pauses still miss extraInfo.

Options

1. Preferred: send Network.enable un-awaited, keep the promise, and have the transport await it before extraInfo lookups on that session. Fetch interception is installed before the worker is released, so nothing escapes while we wait — this blocks a request briefly rather than the debugger.
2. Have CDPNetworkExtraInfo observe the browser connection, where Network is already enabled for SW targets, joining via targetInfo.targetId. Risk: CDP request ids are per-session, so the same request may not share an id across connections.
3. Accept the drift and record it in the proxy-disabled behavior-changes log.

Acceptance criteria

Nothing detects this today, so the fixture is really the deliverable that decides whether 1–2 are worth building.

• A fixture (service worker proxying a Set-Cookie response, asserting the simulated-top rewrite) fails without the fix and passes with it — or shows the case is unreachable, and the drift is documented instead
• service-worker.cy.js stays 28/28 proxy-off on Chrome and Electron, no wall-clock regression
• service_worker_spec.js / service_worker_protocol_spec.js stay green proxy-off
• MITM behavior unchanged

system-tests-electron-cdp-remediated carries no service-worker specs — worth closing while here.

[baus]

Complexity: 4 — This requires reconciling two independent Target.attachedToTarget listeners (cri-client.ts and browser-cri-client.ts) that each have different Network.enable logic for service-worker sessions, deciding how CDPNetworkExtraInfo/CdpFetchTransport should be instantiated for SW targets (the "extra target" pattern in network-runtime.ts is a precedent but isn't wired up for service workers), and doing all of it without reintroducing the documented Network.enable/Runtime.runIfWaitingForDebugger deadlock that dropped service-worker.cy.js from 28/28 to 0 passing in a prior attempt. The issue itself presents three candidate designs without settling on one, and touches a large, regression-sensitive test surface (service-worker.cy.js, cdp-network-extra-info_spec.ts, cdp-fetch-transport_spec.ts, browser-cri-client_spec.ts, network-runtime_spec.ts) plus a new fixture. It's multi-subsystem within the CDP/proxy layer with real design uncertainty, but scoped enough (not spanning unrelated packages) to stay short of a 5.

---

Generated by Claude Code

[AtofStryker]

This is not scoped for MVP

[baus]

Complexity: 4 — The preferred fix spans multiple subsystems: CDP target-attach lifecycle (browser-cri-client.ts/cri-client.ts, which already have inconsistent service_worker handling between the two classes), the CDPNetworkExtraInfo correlation logic (a single instance shared across sessions with no existing per-session promise registry, so threading an un-awaited Network.enable promise through to its lookup is new cross-class plumbing, not a local tweak), and the Fetch-pause cookie middleware in cdp-fetch-transport.ts. There's also real design uncertainty — the ticket itself weighs three options with unverified assumptions (e.g., whether CDP request IDs match across page/browser connections), a documented deadlock hazard in the attach ordering, and no existing positive test fixture, so a new SW Set-Cookie fixture must be built before the fix can even be verified against the "28/28, no regression on Chrome and Electron" acceptance criteria.

---

Generated by Claude Code

[AtofStryker]

Now that #34567 has landed the same technique for extra targets, the deadlock half of option 1 is proven: Network.enable hangs on both dedicated connections and flattened sessions while paused, Fetch.enable is browser-serviced and settles while paused, and sending Network.enable un-awaited from the attach hook is safe (see the probe matrix in that PR's description).

What's still open here is only the timing refinement. Fire-and-forget alone reproduces the gap:

1. Network.enable is sent un-awaited and settles ~40ms after the worker is released.
2. The earliest SW requests — including the document navigations that are the one case that matters — go to the wire before that.
3. A request issued before Network is active never emits its requestWillBeSentExtraInfo twin, so CDPNetworkExtraInfo skips the hold and the Set-Cookie is lost.

The fix I'd try: gate at the Request-stage Fetch pause, not at extraInfo lookup.

1. Keep the Network.enable promise instead of dropping it.
2. When the first requests hit their Request-stage pause, await that promise before continuing them.
3. The request then transits the wire after Network is active, so the twin and response extraInfo both flow.

Fetch interception is installed before the worker is released, so nothing escapes while we wait — this blocks a request for ~40ms instead of the debugger. The fixture in the acceptance criteria still decides whether any of this is worth building.