SSE and NDJSON response streams drain unread sources without backpressure

[dakjdakd]

TanStack AI version

@tanstack/ai@0.63.0; reproduced on clean main at 62bec34bb.

Framework/Library version

Node.js 24.11.1, native WHATWG ReadableStream; no framework or provider credentials required.

Describe the bug and the steps to reproduce it

toHttpStream() (NDJSON) and toServerSentEventsStream() (SSE) continue consuming their AsyncIterable even when nobody reads the returned response stream. toEncodedStream() starts its pump in ReadableStream.start() (packages/ai/src/stream-to-response.ts:167-175 on the commit above), then calls iterator.next() and controller.enqueue() repeatedly (:176-186) without checking controller.desiredSize. The default stream queue therefore does not limit source consumption. A stalled HTTP reader can accumulate the complete response in memory.

From the repository root, save this as repro-backpressure.mts and run pnpm exec tsx repro-backpressure.mts:

import {
  toHttpStream,
  toServerSentEventsStream,
} from './packages/ai/src/stream-to-response.ts'

for (const [name, encode] of [
  ['SSE', toServerSentEventsStream],
  ['NDJSON', toHttpStream],
] as const) {
  let produced = 0
  async function* source() {
    for (let i = 0; i < 10_000; i++) {
      produced++
      yield {
        type: 'TEXT_MESSAGE_CONTENT' as const,
        messageId: 'm',
        timestamp: Date.now(),
        delta: 'x',
      }
    }
  }

  const response = encode(source())
  await new Promise((resolve) => setTimeout(resolve, 50))
  console.log(`${name}: pulled ${produced} chunks without a reader`)
  await response.cancel()
  if (produced !== 1) process.exitCode = 1
}

Actual on clean main: both formats drain the source despite having no reader:

SSE: pulled 10000 chunks without a reader
NDJSON: pulled 10000 chunks without a reader
exit 1

Expected: one chunk may occupy the default queue. The producer should pause until a reader consumes that chunk. Running the same probe on the proposed fix prints SSE: pulled 1 chunks without a reader and NDJSON: pulled 1 chunks without a reader, exit 0.

The source-level regression test also checks that reading one chunk resumes production, that cancellation cleans up the source, and that an error from a paused source reaches the reader. It is on the proposed branch.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

Runnable repository regression test. The complete standalone probe is inline above; it uses only the source checkout and Node's native streams.

User impact

An endpoint that hands a long or fast model output to either helper can keep requesting provider chunks after its downstream client stalls. Memory use then grows with the entire response instead of with the stream's queue. This is especially relevant to long-running responses and clients on slow connections.

Scope and existing reports

Searched repository Issues and PRs for backpressure, slow client, unbounded stream, buffering stream, and response stream on 2026-09-28; found no report of this SSE/NDJSON response-queue behavior. PR #1541 concerns generated-media upload streaming; PR #969 concerns WebSocket transport. Neither addresses this encoder.

Do you intend to try to help solve this bug with your own PR?

Yes. A separate PR will link this issue.

Screenshots or Videos (Optional)

Not applicable; the producer count is asserted directly.

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct.
• I understand that a bug without a reliable reproduction can be closed.