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

[daveycodez]

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.