Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

SSE and NDJSON response streams drain unread sources without backpressure

Abierto
#1,556 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@tombeckenham ya está trabajando en esto.

Desde el 28/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

has-pr waiting-on: maintainer

TanStack AI version

@tanstack/[email protected]; 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.
Lenguaje dominante
TypeScript
Estrellas
3.1k
Forks
340
Merge medio
2 d 7 h
PR fusionados (30 d)
175

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TanStack/ai

Todos los issues de TanStack/ai

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.