Summary

A single assistant turn on OpenClaw 2026.4.8 entered pathological retry churn, repeatedly reissuing near-identical requests to the same model/provider before falling back to other candidates. The session stayed in processing, queueDepth=0, and no user-visible output appeared until a later fallback finally succeeded.

This does not look like duplicate queued tasks or multiple fresh runs. It appears to be one stuck run repeatedly retried.

Environment

• OpenClaw: 2026.4.8
• Surface: Telegram direct chat
• Session: agent:main:main
• Observed date: 2026-04-08
• Timezone: Europe/Berlin

What was observed

From the provider/request view, the same turn kept making repeated calls with almost the same request size. The screenshot showed constant retries on the same model with only very small prompt-size changes between attempts.

From gateway logs, the same runId persisted across the whole incident:

• runId=986fae75-fe4e-45dc-91cc-1810c89abe8b

Behavior observed:

• repeated requests with nearly identical payload size
• repeated attempts on the same model/provider candidate before moving on
• later cross-provider fallback
• session remained stuck in processing
• queueDepth=0
• no visible response until the last fallback succeeded

Relevant logs

2026-04-08T20:56:47.937+02:00 [agent] embedded run timeout: runId=986fae75-fe4e-45dc-91cc-1810c89abe8b sessionId=1fedc66d-f400-403a-a267-3c15de01ecfc timeoutMs=120000
2026-04-08T20:57:01.279+02:00 [agent] Profile moonshot:default timed out. Trying next account...
2026-04-08T20:57:01.286+02:00 [agent] embedded run failover decision: runId=986fae75-fe4e-45dc-91cc-1810c89abe8b stage=assistant decision=fallback_model reason=timeout provider=moonshot/kimi-k2.5 profile=sha256:a3568bc3c72e
2026-04-08T20:57:01.317+02:00 [model-fallback] model fallback decision: decision=candidate_failed requested=moonshot/kimi-k2.5 candidate=moonshot/kimi-k2.5 reason=timeout next=openrouter/qwen/qwen3.6-plus detail=LLM request timed out.
2026-04-08T20:59:11.537+02:00 [agent] embedded run timeout: runId=986fae75-fe4e-45dc-91cc-1810c89abe8b sessionId=1fedc66d-f400-403a-a267-3c15de01ecfc timeoutMs=120000
2026-04-08T20:59:12.490+02:00 [diagnostic] stuck session: sessionId=main sessionKey=agent:main:main state=processing age=121s queueDepth=0
2026-04-08T20:59:37.028+02:00 [agent] Profile openrouter:default timed out. Trying next account...
2026-04-08T20:59:37.032+02:00 [agent] embedded run failover decision: runId=986fae75-fe4e-45dc-91cc-1810c89abe8b stage=assistant decision=fallback_model reason=timeout provider=openrouter/qwen/qwen3.6-plus profile=sha256:ac092b59b472
2026-04-08T20:59:37.154+02:00 [model-fallback] model fallback decision: decision=candidate_failed requested=moonshot/kimi-k2.5 candidate=openrouter/qwen/qwen3.6-plus reason=timeout next=openrouter/qwen/qwen3.5-397b-a17b detail=LLM request timed out.
2026-04-08T20:59:59.238+02:00 [model-fallback] model fallback decision: decision=candidate_succeeded requested=moonshot/kimi-k2.5 candidate=openrouter/qwen/qwen3.5-397b-a17b reason=unknown next=none

Why this looks buggy

The concerning part is not ordinary model failover by itself. It is the combination of:

• one persistent runId
• same turn apparently being reissued multiple times
• repeated near-identical request sizes on the same model/provider candidate
• session marked stuck while queueDepth=0
• eventual success only after extended retry churn

This burns credits and latency while making the system look like it is looping from the provider side, even though it is still one logical turn.

What had already been ruled out

• This was not caused by stale TaskFlow rows continuing to run. Related task rows had already been manually cleaned from SQLite before analysis.
• This did not appear to be multiple fresh user turns.
• This did not appear to be a queue backlog (queueDepth=0).

Expected behavior

Once an assistant turn has timed out and the session is already stuck in processing, OpenClaw should either:

1. abort the active attempt cleanly and fail over once, or
2. terminate the turn with a clear error,

but it should not keep reissuing near-identical assistant requests on the same stuck turn.

Suspected area

Possibly an interaction between:

• embedded runner timeout handling
• provider/account retry logic
• model fallback logic
• stuck-session handling for assistant stage
• context/bootstrap/compaction re-entry during failover

Nice-to-have diagnostics

If useful, exposing per-run retry counters and clearly distinguishing:

• same-candidate retry
• same-provider different-profile retry
• cross-provider fallback

would make this much easier to diagnose.