fix(ai-llm-proxy): prevent mid-flight request cancellation from wasting LLM cost

[LukasHirt]

Summary

Proactive follow-up (no tracked issue) addressing user-reported "AI proxy requests cancelled mid-flight" behavior. Prior research identified two independent root causes across the client → proxy → upstream LLM request chain, both fixed here.

Root cause 1 — client-side timeouts fire before the proxy's own timeout, and are inconsistent

Every web-app-ai-* (and a couple non-AI) composable calling the ai-llm-proxy set its own AbortSignal.timeout(...), with inconsistent values of either 30s or 60s. The proxy itself allows up to 60s for its own upstream LLM fetch, plus unaccounted latency before that for OIDC discovery/userinfo validation. Any composable using the 30s value could abort a request the proxy was still legitimately working on.

Fix: raised and unified every client-side AbortSignal.timeout(...) call that hits the ai-llm-proxy to 90_000 (90s) — comfortably above the proxy's 60s upstream timeout — with a one-line comment at each call site. Left untouched: the 10s vision-capability probe in web-app-ai-image-alt-text-sidebar, and web-app-ai-smart-collections-nav's useRecentFiles.ts REQUEST_TIMEOUT_MS (a WebDAV REPORT/getFileContents timeout, not an LLM call).

Also added missing TimeoutError-specific error handling (matching the message style already used by sibling packages) to the two composables that lacked it entirely:

• web-app-ai-sensitive-data-scanner (useLlm.ts / useScanner.ts)
• web-app-ai-quick-draft-creator (useLLM.ts) — this one needed the outbound fetch wrapped in its own try/catch, since a timeout abort rejects the fetch itself before there's a Response to check .ok on.

Root cause 2 — the proxy never notices the client disconnected

In packages/ai-llm-proxy/src/index.ts's handleRequest, once the outbound fetch to the LLM endpoint started, there was no listener for the client request's 'close' event. If the client's own timeout fired, the tab closed, or the connection dropped, the proxy kept awaiting the full upstream LLM response (up to 60s) — burning LLM cost for a response nobody would receive — then tried to write to an already-dead response.

Fix:

• Wired an AbortController into handleRequest, aborted on the request's 'close' event.
• Combined that controller's signal with the existing upstream timeout via AbortSignal.any([...]), so either condition stops the outbound fetch.
• Guarded sendJson and the final response write against a disconnected client (res.writableEnded/res.destroyed checks).
• Attached a no-op res.on('error', () => {}) listener so a write-after-close can never crash the process via an unhandled 'error' event.
• Added unit tests proving the outbound fetch's abort signal fires on client disconnect, and that no write/crash occurs afterwards.

Verification

Per touched package, ran (or the equivalent for ai-llm-proxy, which has no check:types/lint script, so tsc/scoped eslint were used instead):

• check:types — all pass
• lint — 0 errors (only pre-existing warnings unrelated to these changes)
• test:unit — all pass, including 5 new tests in packages/ai-llm-proxy/tests/unit/proxy.spec.ts (28/28 total in that file)

Packages covered: ai-llm-proxy, web-app-ai-data-insights-sidebar, web-app-ai-doc-summary, web-app-ai-folder-brief-sidebar, web-app-ai-folder-readme-generator, web-app-ai-image-alt-text-sidebar, web-app-ai-multi-doc-synthesizer, web-app-ai-quick-draft-creator, web-app-ai-sensitive-data-scanner, web-app-ai-smart-collections-nav, web-app-ai-smart-file-tagger-qa, web-app-chat-with-file, web-app-version-changelog.

Test plan

• ai-llm-proxy unit tests cover the new disconnect-abort behavior and write-after-close safety
• Every touched web-app package's existing unit tests still pass with the new timeout value
• Manual read-through of every call site to confirm the 90s value and comment were applied correctly, and that unrelated timeouts (10s vision probe, WebDAV REPORT timeout) were left alone

Follow-up: client timeout raised from 90s to a 5-minute safety net

The 90_000 (90s) client-side timeout above was chosen to comfortably exceed the proxy's hardcoded 60s upstream timeout. However, a separate, still-open PR (#530, feat/ai-llm-proxy-configurable-timeout) makes that upstream timeout configurable via LLM_TIMEOUT_MS (default unchanged at 60s, but with no fixed upper bound). If an admin sets LLM_TIMEOUT_MS above 90s to accommodate a slower self-hosted model, the client's 90s timeout would again fire before the proxy's configured timeout — reintroducing the exact mid-flight cancellation bug this PR fixes, just at a different threshold.

Fix: raised every client composable's AbortSignal.timeout(...) from 90_000 to 300_000 (5 minutes), and reworded the accompanying comments accordingly. The client-side timeout is no longer meant to closely track the proxy's own upstream timeout — it's now a generous, fixed outer bound whose only job is to prevent the browser tab from hanging indefinitely if the network or the proxy process itself never responds at all (e.g. a killed container, a dropped TCP connection with no FIN, or a proxy that hangs before even starting its upstream fetch). The proxy's own (separately configurable) timeout remains the authoritative, real cutoff for how long an LLM call is allowed to run.

Left untouched: the proxy's own AbortSignal.timeout(60_000) in packages/ai-llm-proxy/src/index.ts (governed by #530, out of scope here), the 10s vision-capability probe in web-app-ai-image-alt-text-sidebar, and web-app-ai-smart-collections-nav's useRecentFiles.ts WebDAV timeout.

Verified check:types, lint, and test:unit pass for all 12 touched web-app-* packages after the change.

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.