openclaw - 💡(How to fix) Fix [Feature/Bug]: Expose undici connect.timeout for Ollama provider + make fallback decision consistent on reason=timeout [1 participants]

Summary

Two related asks affecting remote-Ollama setups:

1. Feature: Expose the undici connect.timeout (TCP connect) so operators running Ollama on a different host (LAN, tailnet) can tolerate slow first-byte responses. Today it is hardcoded to undici's default 10 s and is not reachable from openclaw.json.
2. Bug: For the same reason=timeout from ollama/<model>, the model-fallback/decision sometimes resolves to decision=fallback_model (and recovers via the configured chain) and sometimes to decision=surface_error (no fallback attempted). The chosen path appears non-deterministic for what looks like the same failure mode.

Environment

• OpenClaw 2026.4.15
• Host: Linux (Ubuntu), gateway running as systemd user service
• Ollama: remote, http://192.168.68.82:11434 (LAN)
• Configured chain (relevant entry):
  • primary: ollama/gemma4-team
  • fallbacks: [\"ollama/qwen72b-team\"] (and ultimately claude-cli/claude-opus-4-7 from defaults)

Evidence — fallback inconsistency

Same gateway, same target (ollama/gemma4-team → 192.168.68.82:11434), same reason=timeout, two different decisions within ~50 minutes:

Run A — 2adb9632-2f8d-4ab0-a1bc-80c4d9107b0e (01:53 UTC): ``` [agent/embedded] embedded run agent end: ... isError=true model=gemma4-team provider=ollama error=LLM request failed: network connection error. rawError=fetch failed | Connect Timeout Error (attempted address: 192.168.68.82:11434, timeout: 10000ms) [agent/embedded] embedded run failover decision: ... stage=assistant decision=fallback_model reason=timeout from=ollama/gemma4-team profile=- [model-fallback/decision] model fallback decision: decision=candidate_failed requested=ollama/gemma4-team candidate=ollama/gemma4-team reason=timeout next=claude-cli/claude-opus-4-7 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=ollama/gemma4-team candidate=claude-cli/claude-opus-4-7 reason=unknown next=none ``` Result: recovered via fallback to Opus 4.7. ✅

Run B — a4d41d27-de26-42f2-8f36-5037132eff5c (02:42 UTC): ``` [agent/embedded] embedded run failover decision: ... stage=assistant decision=surface_error reason=timeout from=ollama/gemma4-team profile=- ``` Result: error surfaced to user, no fallback attempted. ❌

Both runs hit the same Connect Timeout Error to the same address with the same configured chain. The branching point that produces surface_error vs fallback_model is not obvious from the logs.

Evidence — connect.timeout not configurable

dist/undici-global-dispatcher-yJO9KyXW.js builds the global dispatcher with bodyTimeout and headersTimeout honoring the embedded-run timeout (per #63175), but the connect block only sets autoSelectFamily / autoSelectFamilyAttemptTimeout — never a connect.timeout. Effective TCP connect timeout is undici's default (10 s).

For LAN/tailnet Ollama the first request after warm-up of a large model (or transient packet loss) easily exceeds 10 s, surfacing the Connect Timeout Error even though the host is healthy. There is no openclaw.json knob to raise it; only an upstream-source patch helps.

Asks

1. Add a config knob — e.g. models.providers.<id>.connectTimeoutMs or a global infra.net.connectTimeoutMs — that propagates into the undici Agent({ connect: { timeout } }).
2. Audit the failover decision branch so reason=timeout from=ollama/* is treated consistently — either always fallback_model (preferred) or document the conditions that produce surface_error so operators know when to expect it.

Workarounds I rejected

• Patching dist/undici-global-dispatcher-yJO9KyXW.js locally — reverted on next npm i -g openclaw.
• Pre-warming the model — masks the timeout but doesn't fix the fallback-policy inconsistency.

Happy to provide a sanitized openclaw.json, more log slices, or test a candidate fix.