feat(ai): add a timeout option to chat(), matching the media activities
Maintainers usually reply within 1 day
@AlemTuzlak is already working on this.
Since Sep 26, 2026.
Assessment
This issue has not been assessed yet.
Description
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 onechat()invocation, with no default. It would be built oncreateActivityAbortControls, and the effective signal passed to the adapter the same way the media activities do it.chat()would also use the sharedcombineAbortSignals.- Because adapters may ignore the signal, the stream's reads should also be raced against it (the
raceWithAbortidea applied pernext()), so a stalled iterator still rejects. - A timeout is an abort for middleware (
onAbort, notonError), with a distinguishable reason: the existingTimeoutErrorfromcreateTimeoutReason. 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
onAbortexactly once, notonError. - Completion clears the timer.
- Dominant language
- TypeScript
- Stars
- 3.1k
- Forks
- 340
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 174
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from TanStack/ai
-
StreamProcessor ignores the stream's message ids and files agent-loop calls on the wrong assistant messagePossibly taken @tombeckenham claimed this 1 day ago. Openwaiting-on: maintainer
TanStack/ai#1533 · 1 assignee ·
Maintainers usually reply within 1 day
-
StreamProcessor drops TEXT_MESSAGE_CHUNK events without a warningPossibly taken @AlemTuzlak claimed this 1 day ago. Openwaiting-on: maintainer
TanStack/ai#1531 · 1 assignee ·
Maintainers usually reply within 1 day
-
Does a hosted provider package have to carry a key?Possibly taken @AlemTuzlak claimed this 3 days ago. Openwaiting-on: author
TanStack/ai#1506 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
-
Client tools never execute against spec-compliant AG-UI servers (plain `success` RUN_FINISHED)Possibly taken @jherr claimed this 5 days ago. Openwaiting-on: maintainer
TanStack/ai#1464 · 1 reaction · 1 assignee ·
Maintainers usually reply within 1 day
-
Add ai to awesome-ai-plugins?Possibly taken @tombeckenham claimed this 11 days ago. Openwaiting-on: maintainer
TanStack/ai#1382 · 1 assignee ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoft/vscode-livepreview#876 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100
JustJarethB/invoicer#54 ·
-
ICP 1.2.0 shows a scheduled task's interval in milliseconds under the label "Interval (In seconds)"OpenNeeds Triage Type/Bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
wso2/product-integrator#2585 ·
Maintainers usually reply within 1 day
-
check:passed streams:add
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
design
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MTES-MCT/monitor-field#119 ·
Maintainers usually reply within 1 day