fix: add default 120s request timeout when provider timeoutSeconds is not configured

Andrew199012 · Andrew199012 · commit 77f1e8cc9017 · 2026-05-09T18:55:11.000+08:00
When models.providers.&lt;id&gt;.timeoutSeconds is not set in config.yaml,
resolveProviderRequestTimeoutMs() returns undefined, which cascades
through buildTimeoutAbortSignal({timeoutMs: undefined}) → no AbortSignal
→ fetch() hangs indefinitely on TCP connections.

This is a P0 defect causing session stalls when upstream API (e.g.
DeepSeek) takes long to respond, leading to event loop congestion and
system unresponsiveness.

Fix: return DEFAULT_REQUEST_TIMEOUT_MS (120s) as fallback instead of
undefined, matching the common expectation that all HTTP requests
should have a bounded timeout.
diff --git a/src/agents/pi-embedded-runner/model.ts b/src/agents/pi-embedded-runner/model.ts
@@ -65,6 +65,9 @@ type ProviderRuntimeHooks = {
   normalizeProviderTransportWithPlugin: typeof normalizeProviderTransportWithPlugin;
 };
 
+/** 当 provider timeoutSeconds 未配置时使用的默认请求超时时间（毫秒） */
+const DEFAULT_REQUEST_TIMEOUT_MS = 120_000;
+
 const TARGET_PROVIDER_RUNTIME_HOOKS: ProviderRuntimeHooks = {
   buildProviderUnknownModelHintWithPlugin,
   prepareProviderDynamicModel,
@@ -336,13 +339,14 @@ function resolveConfiguredProviderDefaultApi(
   return providerConfig?.baseUrl ? "openai-completions" : undefined;
 }
 
-function resolveProviderRequestTimeoutMs(timeoutSeconds: unknown): number | undefined {
+function resolveProviderRequestTimeoutMs(timeoutSeconds: unknown): number {
   if (
     typeof timeoutSeconds !== "number" ||
     !Number.isFinite(timeoutSeconds) ||
     timeoutSeconds <= 0
   ) {
-    return undefined;
+    // provider timeoutSeconds 未配置或 <=0 时，回退到 120 秒默认超时，避免 HTTP 请求无限等待
+    return DEFAULT_REQUEST_TIMEOUT_MS;
   }
   return Math.floor(timeoutSeconds) * 1000;
 }
