openclaw - 💡(How to fix) Fix Cron isolated agentTurn: LLM request hangs for full job timeout — no per-request timeout [1 participants]

Summary

Isolated agentTurn cron jobs intermittently hang for their entire timeoutSeconds budget on the initial LLM API call, with the Anthropic API never responding. The job timeout is consumed by a single hanging request, leaving no time for the actual task or fallback retries.

Regular interactive sessions on the same profile, same API key, same model work fine simultaneously.

Environment

• OpenClaw: running from source (dev channel, ~2026.3.23)
• Model: anthropic/claude-opus-4-6 (also reproduces on anthropic/claude-sonnet-4-6)
• Auth: single profile (anthropic:manual, mode=token)
• OS: Ubuntu, systemd user service

Symptoms

Auth refresh cron job (agentTurn, isolated, runs 3x daily at 06/14/22:00):

• When it works: 25-35s total (API responds in ~2s, script runs ~20s)
• When it fails: Hangs for exactly timeoutSeconds (120s or 240s), then:

  Profile anthropic:manual timed out. Trying next account...
  FailoverError: LLM request timed out.
  model-fallback: candidate_failed reason=timeout next=none

137 timeout events in one log file (~1 week), all on cron runs. Zero on interactive sessions.

Failure pattern (from run history)

Even "successful" runs sometimes take 147-157s for a job that completes in 25s when the API responds promptly — suggesting the LLM request itself takes 120-130s before finally responding.

Root cause analysis

The timeoutSeconds on the cron payload is used as the overall job budget. When the initial LLM API call hangs (status 408), it consumes the entire budget. There is no separate, shorter per-request timeout that would allow:

1. Detecting a hung request early (e.g. 30s)
2. Retrying on the same or fallback model
3. Leaving time for the actual task execution

The model-fallback code does fire, but only after the full timeout — at which point there's no budget left.

Expected behavior

• LLM API requests should have a per-request timeout (e.g. 60s) independent of the job timeout
• If a request hangs, the fallback system should retry with time remaining
• A job with timeoutSeconds: 240 should not spend all 240s on a single hung API call

Workaround attempts

• Bumped timeoutSeconds from 120 to 240 — helps marginally but still fails
• Switched model from Opus to Sonnet — same issue
• Manual runs of the same script from interactive sessions work consistently in 25s

Related issues

• #42632 — same symptom (isolated agentTurn timeout on minimal prompt)
• #40237 — WS self-contention (different root cause but similar presentation)
• #34644 — feature request for configurable embedded agent LLM-request timeout

Suggested fix

Add a configurable agents.defaults.llmRequestTimeoutSeconds (or per-job payload.llmRequestTimeoutSeconds) that caps individual LLM API calls, defaulting to something like 60-90s. The overall job timeout should be the outer budget, not the per-request timeout.