fix(sse): cap streaming headers-wait timeout to a client-realistic ceiling (#11526)

The fetch-start (headers-wait) phase inherited the flat, non-adaptive
FETCH_TIMEOUT_MS (default 600_000ms) with no ceiling comparable to a real
client's patience, unlike the body-phase readiness watchdog which already
adapts per payload shape. Codex's own hard client-abort window for a
stalled turn is ~120s, 5x shorter than the old default — so when an
upstream never returned any response at all (not even headers, e.g. a
stalled NVIDIA target behind a tool-heavy Responses->Chat translation),
OmniRoute kept the connection open on keepalives only, guaranteeing the
client gave up first with an opaque 499 instead of OmniRoute detecting and
failing the stall fast.

Adds resolveFetchStartTimeout() (open-sse/utils/fetchStartTimeoutPolicy.ts)
that caps the headers-wait timeout to 110s for STREAMING requests only,
leaving non-streaming requests on the existing flat default. Wired into
BaseExecutor.execute(). The existing TimeoutError classification path
(chatCore.ts) already maps this to a 504, so no change was needed there.

Regression test: tests/unit/issue-11526-repro.test.ts.

changelog.d/fixes/11526-responses-headers-phase-timeout-cap.md

@@ -0,0 +1 @@
+- **fix(sse):** cap the upstream headers-wait phase for STREAMING requests to a client-realistic ceiling (110s, under Codex's own ~120s hard client-abort window) instead of the flat 10-minute `FETCH_TIMEOUT_MS` default — that default was 5x longer than the body-phase readiness watchdog's own adaptive bound, so a request whose upstream never returned any response at all (not even headers, e.g. a stalled NVIDIA target behind a tool-heavy Responses→Chat translation) kept the client connection alive on keepalives only, guaranteeing the client's own patience ran out first with an opaque 499 instead of OmniRoute detecting and failing the stall fast. Non-streaming requests are unaffected — they keep the existing flat default (`open-sse/utils/fetchStartTimeoutPolicy.ts`) (#11526)

open-sse/executors/base.ts

@@ -1,5 +1,6 @@
 import { HTTP_STATUS, FETCH_TIMEOUT_MS } from "../config/constants.ts";
 import { getRegistryEntry } from "../config/providerRegistry.ts";
+import { resolveFetchStartTimeout } from "../utils/fetchStartTimeoutPolicy.ts";
 import {
   resolveAlternateFormat,
   type AlternateFormat,
@@ -902,9 +903,24 @@ export class BaseExecutor {
         clampNestedThinkingBudget(transformedBody, thinkingBudgetClampedMax);
       }
 
+      // Timeout only covers response start; stream stalls are handled downstream.
+      // #11526: streaming requests cap the headers-wait phase to a client-realistic
+      // ceiling (see fetchStartTimeoutPolicy.ts) — non-streaming keeps the flat default.
+      // Declared outside the try/catch below so the catch's TIMEOUT log (on the
+      // error path) reports the same effective value the fetch actually used.
+      const fetchStartTimeoutPolicy = resolveFetchStartTimeout({
+        baseTimeoutMs: this.getTimeoutMs(),
+        stream,
+      });
+      const fetchStartTimeoutMs = fetchStartTimeoutPolicy.timeoutMs;
+      if (fetchStartTimeoutPolicy.capped) {
+        log?.debug?.(
+          "TIMEOUT",
+          `fetch-start timeout capped ${fetchStartTimeoutPolicy.baseTimeoutMs}ms -> ${fetchStartTimeoutMs}ms (streaming)`
+        );
+      }
+
       try {
-        // Timeout only covers response start; stream stalls are handled downstream.
-        const fetchStartTimeoutMs = this.getTimeoutMs();
         const fetchWithStartTimeout = async (requestUrl: string, requestOptions: RequestInit) => {
           // GHSA-4f49: guard here (not only next to the first buildUrl) so retries
           // and fallback URLs are validated too, before any bytes leave the host.
@@ -1713,7 +1729,7 @@ export class BaseExecutor {
         // Distinguish timeout errors from other abort errors
         const err = error instanceof Error ? error : new Error(String(error));
         if (err.name === "TimeoutError") {
-          log?.warn?.("TIMEOUT", `Fetch timeout after ${this.getTimeoutMs()}ms on ${url}`);
+          log?.warn?.("TIMEOUT", `Fetch timeout after ${fetchStartTimeoutMs}ms on ${url}`);
         }
         lastError = err;
         if (!skipUpstreamRetry && urlIndex + 1 < fallbackCount) {

open-sse/utils/fetchStartTimeoutPolicy.ts

@@ -0,0 +1,52 @@
+// #11526: the fetch-start (headers-wait) phase had no ceiling comparable to a
+// real client's patience for STREAMING requests — it inherited the flat,
+// non-adaptive FETCH_TIMEOUT_MS (default 600_000ms / 10 minutes), five times
+// longer than Codex's own ~120s hard client-abort window. When an upstream
+// never returns a response at all (not even headers), OmniRoute kept the
+// connection open with nothing but keepalives, guaranteeing the client gave
+// up first with an opaque 499 instead of OmniRoute detecting the stall and
+// failing fast/over within a client-realistic window.
+//
+// This mirrors the adaptive philosophy of streamReadinessPolicy.ts's
+// resolveStreamReadinessTimeout (which already protects the BODY phase, after
+// headers arrive) but inverted: instead of bumping a small base timeout up for
+// heavy payloads, it caps an oversized base timeout down for the HEADERS
+// phase of streaming requests specifically. Non-streaming requests are left
+// on the existing flat default — providers that are legitimately slow to
+// accept a connection (but not streaming SSE) are unaffected.
+
+export type FetchStartTimeoutPolicyInput = {
+  baseTimeoutMs: number;
+  /** Only streaming requests are capped — non-streaming keeps the flat default. */
+  stream?: boolean | null;
+  capMs?: number;
+};
+
+export type FetchStartTimeoutPolicyResult = {
+  timeoutMs: number;
+  baseTimeoutMs: number;
+  /** True when the base timeout was reduced by the streaming cap. */
+  capped: boolean;
+};
+
+// Codex's documented hard client-abort window for a stalled turn (nothing but
+// keepalives in flight) is ~120s. Keep the cap safely under that so OmniRoute's
+// own headers-phase watchdog always fires before the client gives up on its own.
+export const CODEX_CLIENT_ABORT_MS = 120_000;
+export const DEFAULT_FETCH_START_TIMEOUT_CAP_MS = 110_000;
+
+export function resolveFetchStartTimeout(
+  input: FetchStartTimeoutPolicyInput
+): FetchStartTimeoutPolicyResult {
+  const baseTimeoutMs = Math.max(0, Math.floor(input.baseTimeoutMs || 0));
+  if (baseTimeoutMs <= 0 || !input.stream) {
+    return { timeoutMs: baseTimeoutMs, baseTimeoutMs, capped: false };
+  }
+
+  const capMs = Math.max(0, Math.floor(input.capMs ?? DEFAULT_FETCH_START_TIMEOUT_CAP_MS));
+  if (capMs <= 0 || baseTimeoutMs <= capMs) {
+    return { timeoutMs: baseTimeoutMs, baseTimeoutMs, capped: false };
+  }
+
+  return { timeoutMs: capMs, baseTimeoutMs, capped: true };
+}

tests/unit/issue-11526-repro.test.ts

@@ -0,0 +1,63 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import { resolveStreamReadinessTimeout } from "../../open-sse/utils/streamReadinessPolicy.ts";
+import {
+  resolveFetchStartTimeout,
+  CODEX_CLIENT_ABORT_MS,
+} from "../../open-sse/utils/fetchStartTimeoutPolicy.ts";
+import { getUpstreamTimeoutConfig } from "../../src/shared/utils/runtimeTimeouts.ts";
+
+function items(count: number): Array<{ role: string; content: string }> {
+  return Array.from({ length: count }, (_, index) => ({
+    role: "user",
+    content: `message ${index}`,
+  }));
+}
+
+function tools(count: number): Array<{ type: string; name: string }> {
+  return Array.from({ length: count }, (_, index) => ({ type: "function", name: `tool_${index}` }));
+}
+
+test("issue #11526: body-phase readiness watchdog stays comfortably under Codex's ~120s patience for the reported tool-heavy payload shape", () => {
+  const result = resolveStreamReadinessTimeout({
+    baseTimeoutMs: 80_000,
+    provider: "nvidia",
+    model: "some-nvidia-model",
+    body: { input: items(68), tools: tools(16) },
+  });
+
+  assert.ok(
+    result.timeoutMs < CODEX_CLIENT_ABORT_MS,
+    `body-phase watchdog (${result.timeoutMs}ms) must stay under Codex's ~120s patience`
+  );
+});
+
+test("issue #11526 (fixed): headers-phase watchdog for STREAMING requests is bounded under Codex's ~120s patience", () => {
+  const { fetchTimeoutMs } = getUpstreamTimeoutConfig({});
+  // Default FETCH_TIMEOUT_MS (600000ms) is still the flat non-streaming baseline —
+  // the fix does not touch that default, it caps how much of it a STREAMING
+  // request's headers-wait phase is allowed to consume.
+  assert.equal(fetchTimeoutMs, 600_000);
+
+  const streaming = resolveFetchStartTimeout({ baseTimeoutMs: fetchTimeoutMs, stream: true });
+  assert.ok(
+    streaming.timeoutMs <= CODEX_CLIENT_ABORT_MS,
+    `headers-phase watchdog for streaming requests (${streaming.timeoutMs}ms) must not exceed a realistic client abort window (${CODEX_CLIENT_ABORT_MS}ms)`
+  );
+  assert.ok(streaming.capped, "expected the oversized default to be capped for streaming requests");
+});
+
+test("issue #11526 scope guard: non-streaming requests keep the flat FETCH_TIMEOUT_MS default", () => {
+  const { fetchTimeoutMs } = getUpstreamTimeoutConfig({});
+  const nonStreaming = resolveFetchStartTimeout({ baseTimeoutMs: fetchTimeoutMs, stream: false });
+
+  assert.equal(nonStreaming.timeoutMs, fetchTimeoutMs);
+  assert.equal(nonStreaming.capped, false);
+});
+
+test("issue #11526 scope guard: a base timeout already under the cap is left untouched for streaming requests", () => {
+  const result = resolveFetchStartTimeout({ baseTimeoutMs: 30_000, stream: true });
+
+  assert.equal(result.timeoutMs, 30_000);
+  assert.equal(result.capped, false);
+});