fix(cc-compatible): restore upstream SSE and correct stream/combo timeout behavior

[rdself]

Summary

• restore forced upstream SSE for Claude Code-compatible providers while still returning JSON to non-stream clients after the upstream stream completes
• stop aborting active streams on total elapsed fetch time; only enforce the startup timeout before upstream headers arrive
• remove combo timeout caps from validation and settings UI so user-provided values are not artificially limited, while keeping the existing defaults unchanged

Root cause

PR #1188 changed the CC-compatible path to respect client-side stream: false all the way upstream. That regressed third-party Claude Code reverse proxies that only behave correctly when the upstream request is sent as SSE.

Separately, the main fetch timeout was still attached to the full response body. Once a streaming response had started, that signal could still abort an otherwise healthy long-running stream after the configured duration, which conflicted with the intended STREAM_IDLE_TIMEOUT_MS semantics.

The combo timeout editor also had inconsistent hard caps in multiple places, and those caps blocked valid larger user-specified values even though the requested behavior was to preserve the default while not imposing a maximum.

What changed

• chatCore now always sets upstreamStream = true for anthropic-compatible-cc-* providers
• non-stream clients still receive JSON through the existing SSE-to-JSON collection path after the upstream stream finishes
• BaseExecutor now uses the fetch timeout only while waiting for the initial upstream response; after headers arrive, active streams are governed by STREAM_IDLE_TIMEOUT_MS and Undici FETCH_BODY_TIMEOUT_MS
• merged abort signals now preserve the original abort reason, so timeout aborts stay classified as timeouts instead of degrading into generic aborts
• combo runtime timeout max caps were removed from schema validation and dashboard inputs; defaults remain unchanged
• README timeout docs were updated to reflect the corrected streaming semantics

Validation

• node --import tsx/esm --test tests/unit/cc-compatible-provider.test.mjs tests/unit/executor-default-base.test.mjs tests/unit/combo-config.test.mjs
• node --import tsx/esm --test tests/unit/runtime-timeouts.test.mjs tests/unit/chatcore-translation-paths.test.mjs tests/unit/claude-code-compatible-helpers.test.mjs
• targeted follow-up after removing timeout caps: node --import tsx/esm --test tests/unit/combo-config.test.mjs
• push hook full unit suite: 2827 passed, 0 failed

[gemini-code-assist]

Code Review

This pull request refactors the timeout logic to distinguish between the initial connection phase and the subsequent streaming phase, while also increasing the maximum allowed timeout to 20 minutes in the UI and validation schemas. Feedback focuses on a concurrency risk and lack of per-request timeout support due to the use of a static property in the base executor, a potential memory leak and listener exhaustion in the abort signal merging logic, and a formatting error in the README that breaks the Markdown table rendering.

[gemini-code-assist]

The use of a static property for FETCH_START_TIMEOUT_MS is problematic for two reasons:

1. Concurrency Risk: In an asynchronous environment, concurrent requests attempting to set different timeouts would overwrite this shared value, leading to race conditions.
2. Ignored Settings: The execute method (line 326) relies on this static value, which defaults to the global FETCH_TIMEOUT_MS. It does not appear to receive or respect the per-combo timeoutMs setting that was increased to 20 minutes in this PR's schema and UI changes.

To fix this, timeoutMs should be added to the ExecuteInput type and passed through from the combo configuration to the execute method.

[gemini-code-assist]

The insertion of explanatory text and blank lines within the Markdown table breaks its rendering. Markdown tables must be contiguous blocks of text. Additionally, the new rows are missing backticks for variable names, which is inconsistent with the rest of the document.

The suggestion below restores the table's integrity and formatting, moving the explanatory text after the table.

Suggested change

	| `API_BRIDGE_SERVER_REQUEST_TIMEOUT_MS` | `max(API_BRIDGE_PROXY_TIMEOUT_MS, 300000)` | Incoming request timeout on the API bridge server |
	For streaming requests, `FETCH_TIMEOUT_MS` only covers connection setup / waiting for the first upstream response. Once the stream is active, OmniRoute will only abort on an actual stall (`STREAM_IDLE_TIMEOUT_MS`) or Undici body inactivity (`FETCH_BODY_TIMEOUT_MS`).
	| `API_BRIDGE_SERVER_HEADERS_TIMEOUT_MS` | `60000` | Incoming header timeout on the API bridge server |
	| `API_BRIDGE_SERVER_KEEPALIVE_TIMEOUT_MS` | `5000` | Keep-alive timeout on the API bridge server |
	| `API_BRIDGE_SERVER_SOCKET_TIMEOUT_MS` | `0` | Socket inactivity timeout on the API bridge server (`0` disables it) |
	| `API_BRIDGE_SERVER_REQUEST_TIMEOUT_MS` | `max(API_BRIDGE_PROXY_TIMEOUT_MS, 300000)` | Incoming request timeout on the API bridge server |
	| `API_BRIDGE_SERVER_HEADERS_TIMEOUT_MS` | `60000` | Incoming header timeout on the API bridge server |
	| `API_BRIDGE_SERVER_KEEPALIVE_TIMEOUT_MS` | `5000` | Keep-alive timeout on the API bridge server |
	| `API_BRIDGE_SERVER_SOCKET_TIMEOUT_MS` | `0` | Socket inactivity timeout on the API bridge server (`0` disables it) |
	For streaming requests, `FETCH_TIMEOUT_MS` only covers connection setup / waiting for the first upstream response. Once the stream is active, OmniRoute will only abort on an actual stall (`STREAM_IDLE_TIMEOUT_MS`) or Undici body inactivity (`FETCH_BODY_TIMEOUT_MS`).

[gemini-code-assist]

This implementation of mergeAbortSignals adds listeners to the primary signal (usually the client request signal) but never removes them if the operation completes without an abort. In scenarios with multiple fallbacks or retries, each attempt will add a new listener to the same primary signal. This can lead to a MaxListenersExceededWarning in Node.js (default limit is 10) and a small memory leak for the duration of the request. Since Node 18 is supported, AbortSignal.any is not available, but you should consider a mechanism to remove these listeners once the fetch call or the resulting stream is finished.

[Copilot]

Pull request overview

Restores Claude Code-compatible provider reliability by always requesting SSE upstream, fixes fetch timeout semantics so active streams aren’t aborted by total elapsed time, and aligns combo timeout caps to 20 minutes across schema + UI.

Changes:

• Force SSE upstream (Accept: text/event-stream, stream: true) for anthropic-compatible-cc-* while still returning JSON to non-stream clients via SSE→JSON collection.
• Update BaseExecutor timeout behavior to only enforce a “response start” (pre-headers) timeout and preserve abort reasons when merging signals.
• Raise combo runtime timeoutMs caps to 1200000ms across validation and dashboard inputs; update docs and add/adjust unit tests.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/unit/executor-default-base.test.mjs	Adds coverage for abort reason preservation and clearing the startup timeout after headers arrive
tests/unit/combo-config.test.mjs	Verifies schema accepts 20-minute combo default + provider override timeouts
tests/unit/chatcore-translation-paths.test.mjs	Updates expectations for CC-compatible upstream requests to use SSE
tests/unit/cc-compatible-provider.test.mjs	Updates test to confirm SSE is forced upstream while client can still be non-streaming
src/shared/validation/schemas.ts	Raises combo runtime timeoutMs validation cap to 20 minutes
src/app/(dashboard)/dashboard/settings/components/ComboDefaultsTab.tsx	Raises settings UI max timeout to 20 minutes for defaults + overrides
src/app/(dashboard)/dashboard/combos/page.tsx	Raises combo editor advanced timeout max to 20 minutes
open-sse/handlers/chatCore.ts	Forces upstreamStream=true for CC-compatible providers
open-sse/executors/base.ts	Preserves abort reasons when merging signals; applies timeout only until initial response, clearing it after headers
open-sse/config/constants.ts	Updates timeout documentation comment to match “response start” semantics
README.md	Updates timeout documentation to reflect corrected streaming semantics

[Copilot]

The advanced overrides env var table is accidentally broken: the narrative sentence on line 817 interrupts the markdown table, and the API_BRIDGE_SERVER_* rows (818–820) are no longer part of the table formatting. Please keep all rows within the same | ... | ... | ... | table (or move the narrative text below the table) so the README renders correctly.

Suggested change

	For streaming requests, `FETCH_TIMEOUT_MS` only covers connection setup / waiting for the first upstream response. Once the stream is active, OmniRoute will only abort on an actual stall (`STREAM_IDLE_TIMEOUT_MS`) or Undici body inactivity (`FETCH_BODY_TIMEOUT_MS`).
	| `API_BRIDGE_SERVER_HEADERS_TIMEOUT_MS` | `60000` | Incoming header timeout on the API bridge server |
	| `API_BRIDGE_SERVER_KEEPALIVE_TIMEOUT_MS` | `5000` | Keep-alive timeout on the API bridge server |
	| `API_BRIDGE_SERVER_SOCKET_TIMEOUT_MS` | `0` | Socket inactivity timeout on the API bridge server (`0` disables it) |
	| `API_BRIDGE_SERVER_HEADERS_TIMEOUT_MS` | `60000` | Incoming header timeout on the API bridge server |
	| `API_BRIDGE_SERVER_KEEPALIVE_TIMEOUT_MS` | `5000` | Keep-alive timeout on the API bridge server |
	| `API_BRIDGE_SERVER_SOCKET_TIMEOUT_MS` | `0` | Socket inactivity timeout on the API bridge server (`0` disables it) |
	For streaming requests, `FETCH_TIMEOUT_MS` only covers connection setup / waiting for the first upstream response. Once the stream is active, OmniRoute will only abort on an actual stall (`STREAM_IDLE_TIMEOUT_MS`) or Undici body inactivity (`FETCH_BODY_TIMEOUT_MS`).

[Copilot]

The startup timeout uses setTimeout(...) but the returned timer is not unref()'d. With the default (600s), an in-flight request timer can keep the Node process alive longer than expected during shutdown. Consider calling timeoutId.unref?.() after creating the timer (similar to open-sse/services/quotaMonitor.ts:244) or using an approach that doesn't keep the event loop alive.

Suggested change

	}, fetchStartTimeoutMs);
	}, fetchStartTimeoutMs);
	timeoutId.unref?.();

[Copilot]

Timeout logging uses BaseExecutor.FETCH_START_TIMEOUT_MS in the warning message, but the actual timeout duration used for this request is read into fetchStartTimeoutMs earlier. If FETCH_START_TIMEOUT_MS is changed at runtime (e.g., in tests or future dynamic config), the log can report the wrong value. Consider capturing the effective timeout outside the try/catch and using that captured value in the log message.

[diegosouzapw]

Thanks @rdself for this excellent and thorough fix! 🎉 Restoring upstream SSE for CC-compatible providers, correcting the stream timeout semantics, and removing artificial combo timeout caps — all with comprehensive test coverage (2827 tests pass!). We fixed a minor README table formatting issue during integration. Integrated into release/v3.6.6 — will ship with the next release!