Native browser network truncates text/event-stream response bodies to the first fragment

[mbranicky-doxee]

Current behavior

On Cypress 16.0.0, a fetch() POST whose response is Content-Type: text/event-stream reaches the application truncated to its first fragment. The page's stream reader yields only the leading character of the body (<) instead of the full streamed reply.

The same spec passes on Cypress 15.21.1, and passes on 16.0.0 with forceHttp1: true, so the difference is isolated to the native browser network path.

This appears distinct from #34655 (progressive delivery collapsing into one late chunk) and #34623 (never-ending bodies wedging the CDP Fetch pause). Both of those closed before 16.0.0 shipped (2026-09-01), so their fixes are present here. The symptom here is loss of body content, not merely loss of progressive delivery.

Desired behavior

The application should receive the complete text/event-stream body, as it does on 15.x and on 16.0.0 with forceHttp1: true.

Test code to reproduce

Reduced from a real suite (a Vue 2 app with an Express mock). I have not run the snippet below as a
standalone project, so treat it as the shape of the failure rather than a verified minimal repro — happy to
put together a runnable reproduction if that helps triage.

Server (Express) — a finite SSE response:

app.post('/chat', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream')
  res.setHeader('Connection', 'keep-alive')
  res.write(`data: ${JSON.stringify({ text: '<fragment-container><text>hello world</text></fragment-container>' })}\n\n`)
  res.write(`data: [DONE]\n\n`)
  res.end()
})

Application code — consumes the body as a stream:

const response = await fetch('/chat', { method: 'POST', body: '{}' })
const reader = response.body.getReader()   // only the first fragment arrives on Cypress 16

Spec:

it('renders the streamed reply', () => {
  cy.get('[data-cy=send]').click()
  cy.get('[data-cy=reply]').should('contain.text', 'hello world')
  // Cypress 16.0.0: fails, "but the text was '<'"
  // Cypress 15.21.1: passes
  // Cypress 16.0.0 + forceHttp1: passes
})

Notes on what was ruled out

• Reproduced with and without cy.intercept() registered on the endpoint — identical failure, so it is not an interception artefact.
• Reproduced with both non-compliant (\ndata:{...}) and spec-compliant (data: {...}\n\n) SSE framing on the server.
• Reproduced with a freshly wiped Cypress state directory and with retries disabled, so it is deterministic rather than state pollution.

Cypress Version

16.0.0

Node version

24.16.0

Operating System

macOS 26.6 (arm64); also reproduced on cypress/browsers:node-24.20.0-chrome-152.0.7977.64-1-ff-155.0-edge-152.0.4191.53-1 in CI (linux/amd64)

Browser

Chrome 152 (headless)

[AtofStryker]

Thanks for the detailed report. I put the snippets from the issue into a standalone project and ran them against Cypress 16.0.0 with Chrome 152:

https://github.com/AtofStryker/cypress-issue-34786

Both tests pass as written. They pass on the default network path and with forceHttp1: true. The page receives the full text/event-stream body in both cases.

The project has two tests. The first uses the single-event mock from the issue. The second writes one event per character with a short delay between writes. Each test prints how many chunks the page's reader saw.

That chunk count is the only difference I can find between the two paths. On the default path, the page receives the body as the server writes it. The per-character test sees 66 chunks. With forceHttp1, the page receives the whole body as one chunk after the server ends the response. Cypress 15 behaved the same way as forceHttp1.

Here is why. The Cypress 15 proxy compresses a text/event-stream response unless the request's Accept header is exactly text/event-stream. A fetch() call sends Accept: */*, so the response gets compressed. The compressor holds its output until the stream ends. The default path in 16 does not compress, so the page sees the server's own chunking.

I also ran the page in plain Chrome with no Cypress involved. It received 66 chunks, the same as Cypress 16.

One possibility is that the app has only ever seen the stream arrive in one piece, and something in how it handles each chunk breaks on a partial event or fragment. If so, Cypress 15 was masking it. Whether real users hit it depends on how the production backend chunks the stream compared to the mock. I have not confirmed any of this. The reduced snippets do not fail for me.

Could you change the repro project to match your setup? The two spots I most need are marked TODO(reporter):

• server.js: how the real mock writes the stream. One event per token, delays between writes, res.flush(), compression middleware, a dev-server proxy in front of it, or anything else that differs.
• public/index.html: how the app reads the stream, especially anything it does per chunk.