SSE and NDJSON response streams drain unread sources without backpressure
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
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
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de TanStack/ai
-
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
signin with openaiAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
update elevenlabsPosiblemente ocupada @tombeckenham la tomó hace 1 día. Abiertohas-pr waiting-on: maintainer
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
TanStack/ai#1564 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
onAfterToolCall failure records a second, contradictory result for a successful server toolPosiblemente ocupada @AlemTuzlak la tomó hace 2 días. Abiertohas-pr waiting-on: maintainer
TanStack/ai#1558 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Solid useChat drops earlier turns after a reactive request option changesPosiblemente ocupada @AlemTuzlak la tomó hace 2 días. Abiertohas-pr waiting-on: maintainer
TanStack/ai#1552 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de TanStack/ai
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
lichess-org/api#678 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
PostHog/posthog.com#20628 ·
Los mantenedores suelen responder en 1 día
-
bug status:Needs Triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
jupyterlab/jupyterlab#19964 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
agentscope-ai/QwenPaw#8064 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area: notebooks-jupyter bug theme: new notebook frontend
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
posit-dev/positron#16347 · 1 comentario ·
Los mantenedores suelen responder en 1 día