fix(chatCore): stop executeWithUpstreamStartTimeout leaking its abortPromise listener (hedge-cancelled process exit)

[Beexly]

Summary

Fixes the Error [AbortError]: hedge-cancelled process exit (exit code 7) seen on a production instance on 2026-08-31, and hardens the process crash guard around it.

Root cause (mapped from the built chunks back to source and reproduced): executeWithUpstreamStartTimeout in open-sse/handlers/chatCore/upstreamTimeouts.ts registered a { once: true } abort listener for abortPromise on the long-lived client/stream signal and never removed it in finally, so every executor attempt (and every retry) leaked one listener. Promise.race only subscribes once the array literal has been evaluated; when execute() threw synchronously the race never ran, abortPromise was orphaned, and the next hedge cancellation / client disconnect aborted the signal with the string reason that streamHandler.ts forwards. createAbortError() rebuilt it as an AbortError-named Error and rejected a promise nothing awaited. That unhandledRejection reached src/shared/utils/httpClientAbortGuard.mjs, whose handler re-threw it as an uncaughtException, and the process exited.

Commits

1. fix(sse): stop mergeAbortSignals from leaking abort listeners - the listener-hygiene change from fix(sse): stop mergeAbortSignals from leaking abort listeners #12391 (open-sse/executors/base.ts), included so this branch is self-contained. Note: that change is correct but is not on the crash path above.
2. fix(server): stop the crash guard re-throwing combo abort reasons - isClientAbortError() now absorbs AbortErrors and the combo abort reasons from comboAbortReasons.ts (hedge-cancelled, combo-per-model-timeout). Ports the upstream guard tests and makes the child-process tests Windows-portable (a file:// URL instead of a bare path in dynamic import()).
3. fix(chatCore): stop executeWithUpstreamStartTimeout leaking its abortPromise listener - the root-cause fix: keep a handle to the listener and remove it with the others in finally; mark the two race-loser promises as handled so a synchronous throw from execute() can never orphan them. Race semantics are unchanged.
4. fix(server): absorb raw string abort reasons in the crash guard; document the verified crash path - streamHandler.ts aborts with raw string reasons and undici rejects with signal.reason verbatim, so a cancellation can reach process level as a bare string; the guard now absorbs those too. Comments corrected to describe the verified mechanism.

Tests

• New regression tests in tests/unit/chatcore-upstream-timeouts.test.ts (+2; both fail against the previous implementation: one asserts no listener growth after a resolving execute, one asserts that a synchronously throwing execute followed by a late hedge-cancelled abort produces no unhandledRejection).
• tests/unit/httpClientAbortGuard.test.mjs (+9), including a real child-process replay of the production shape on both the uncaughtException and unhandledRejection routes, and a genuine-error case that must still crash.
• Results: httpClientAbortGuard 18/18, chatcore-upstream-timeouts 7/7, executor-base-utils 23/23; 127 related unit test files 968/970 (the 2 failures reproduce identically on the base commit: a stale G13 golden and a Windows temp-dir EPERM on cleanup).
• tsc --noEmit -p open-sse/tsconfig.json clean; eslint clean on the changed files.

Related

• Extends fix(sse): stop mergeAbortSignals from leaking abort listeners #12391, which on its own does not fix the exit.
• Separately observed on Windows and not addressed here: scripts/build/bootstrap-env.mjs resolves DATA_DIR to %APPDATA%\omniroute while src/lib/dataPaths.ts prefers a legacy ~/.omniroute when it exists, so the first npm start of a source checkout can auto-generate a new STORAGE_ENCRYPTION_KEY and orphan every previously encrypted credential. Happy to file it as an issue.

🤖 Generated with Claude Code

[diegosouzapw]

Solid fix for the abort-listener leak, and the extraction of mergeAbortSignals into its own
module with an explicit cleanup() is a real architectural improvement over the inline version.
Verified 47/47 tests pass across the three touched test files. This looks merge-ready. Since this
supersedes your own earlier #12391 with the same fix in a cleaner shape, we'll close that one in
favor of this PR — let us know if you'd rather we merge #12391 instead, but this version is the
more complete one.

[diegosouzapw]

Thanks @Beexly — merging via the release merge-train. Validated in local merge-train /tmp/mt-train3b.log on 192.168.0.113 @ train tip 408e2128791696a18966681953136fc96aeb99b0 (32 PRs boarded): static gates green; full test:unit 40694 tests, 17 failing — every one reproduces on the pure release tip (base-red sweep list), zero new reds. Merged --admin per merge-gates §4/§7.

[diegosouzapw]

Thanks @Beexly — merging via the release merge-train. Validated in local merge-train (merge-train-20260918-130526-suite.log) on the devbox @ train tip 28fb420c9ad860ba275294ebb4ebbecb9da83318 with the sibling PRs of this batch: static gates green; changed-area node:test 293/294 (0 failing) + vitest 482/482 (fast parity — full suite ran today on the tip via the base-red and 3b trains). Merged --admin per merge-gates §7.