fix: abort generateText on webSearch timeout

[sentry-junior]

Problem

JUNIOR-1H — Error: webSearch timed out (15 events, 10 users, ongoing since 2026-04-10)

When webSearch times out after 60s, the underlying generateText() call to the AI Gateway continues running in the background indefinitely. No AbortController signal is passed, so the HTTP request is never cancelled. Retries compound the problem since each one leaves behind another orphaned request leaking connections and memory.

Root Cause

withTimeout() uses Promise.race to implement the deadline, but the losing promise (generateText) is never told to stop. The same file (network.ts) already uses AbortController correctly for fetchTextWithRedirects — the search tool just wasn't wired the same way.

Fix

network.ts — withTimeout

• Added optional onTimeout callback for post-timeout cleanup.
• Reject fires first, then onTimeout runs in a try/catch — so the abort can never race the timeout error, and a throwing cleanup callback cannot break timeout semantics.

search.ts — createWebSearchTool

• Create an AbortController per search call.
• Pass abortSignal: controller.signal to generateText() so the AI SDK cancels the underlying HTTP request on abort.
• Wire onTimeout: () => controller.abort() so the abort fires immediately after the timeout rejection.

Tests

• Added test verifying the AbortSignal is aborted on timeout.
• Added test verifying the signal stays clean on successful search.
• Added test verifying timeout is still correctly reported even when the abort cleanup throws.
• Added abortSignal assertion to the happy-path call-shape test.

Closes JUNIOR-1H

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
junior-docs	Ready	Preview, Comment	May 7, 2026 6:39pm

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d19142c. Configure here.}

[cursor]

Timeout errors still marked retryable despite PR intent

High Severity

The retryable computation on line 135 is !isAuthFailure(message), but the PR explicitly intends to change it to !timeout && !isAuthFailure(message). Without incorporating the timeout variable, timed-out searches are still marked retryable: true, so the retry amplification problem described in the PR (multiple 60s retries burning resources) remains unfixed. The test at line 159 correspondingly still asserts retryable: true instead of false.

Additional Locations (1)

• packages/junior/tests/unit/web/web-search.test.ts#L158-L159

 

^{Reviewed by Cursor Bugbot for commit d19142c. Configure here.}