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

feat(ai): add a timeout option to chat(), matching the media activities

Abierto
  • ¿Algo no está bien?
#1,517 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@AlemTuzlak ya está trabajando en esto.

Desde el 26/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

waiting-on: maintainer

Problem

#981 / #1047 gave the media activities and summarize a shared timeout contract: timeout + abortSignal, composed by createActivityAbortControls. chat() never got one.

packages/ai/src/utilities/activity-abort.ts provides createActivityAbortControls({ abortSignal, timeout }), combineAbortSignals, raceWithAbort and isActivityAbortError. Together they compose the timeout with the caller signal into one effective signal and race the adapter call, so a hung provider still rejects. They also clear the timer on settle and route the abort to middleware onAbort rather than onError. Every generate* activity and summarize uses them.

chat() takes only abortController (activities/chat/index.ts L1019-L1022), keeps its own private copy of combineAbortSignals, and has no timeout option. The abortController doc in types.ts suggests building a timeout by hand with setTimeout(() => abortController.abort(), 5000). So a chat stream that never sends headers, or starts and then goes silent, is bounded only by whatever the caller aborts with.

Provider SDK timeouts don't reliably fill the gap either. Some of them drop their own timeout once a signal is passed, and adapters pass the chat signal down. For example, @openrouter/sdk applies timeoutMs only when no signal is present (OpenRouterTeam/typescript-sdk#1123). A core-level timeout composed into the signal avoids that for every adapter.

Verified in @tanstack/ai 0.58.0 and on main at 3e30cde.

Proposal

await chat({
  adapter,
  messages,
  timeout: 30_000,
  abortController,
})
  • timeout?: number: the maximum duration in ms of one chat() invocation, with no default. It would be built on createActivityAbortControls, and the effective signal passed to the adapter the same way the media activities do it. chat() would also use the shared combineAbortSignals.
  • Because adapters may ignore the signal, the stream's reads should also be raced against it (the raceWithAbort idea applied per next()), so a stalled iterator still rejects.
  • A timeout is an abort for middleware (onAbort, not onError), with a distinguishable reason: the existing TimeoutError from createTimeoutReason. Callers can then tell "timed out" from "caller aborted" and fall back to another model or retry.
  • The timer is cleared when the run settles.
Follow-up (or an option in the same change): streaming deadlines

For long reasoning or streaming outputs, a total cap has to be set high enough not to cut off legitimate slow answers, and then it catches stalls late. Two opt-in deadlines would complement timeout:

  • a first-chunk timeout: from request start to the first parsed stream chunk;
  • an idle timeout: the maximum gap between parsed chunks.

"Chunk" here means a parsed StreamChunk reaching core. SSE keep-alive comments may be dropped by the adapter or SDK before core sees them, so they neither count as progress nor mask a stall. For tool loops, these deadlines would re-arm for each model call.

Motivation

In a production app running many parallel structured chat() calls per request, a rare provider hang held one call until the whole request's deadline (80-118s observed) instead of failing fast and falling back to another model. The workaround today is an app-level AbortController + setTimeout at every call site. That doesn't get onAbort timeout classification, and it duplicates what createActivityAbortControls already does.

Tests (mirroring #1047)

  • A timeout aborts a hung chatStream, including one that ignores the signal.
  • The first of caller abort or timeout wins and keeps its reason.
  • A timeout triggers onAbort exactly once, not onError.
  • Completion clears the timer.
Lenguaje dominante
TypeScript
Estrellas
3.1k
Forks
340
Merge medio
2 d 10 h
PR fusionados (30 d)
174

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.