Summary
On an embedded agent run, the model generation call appears to have no per-call timeout. When the provider call hangs, the run sits with no progress indefinitely until the stuck-session watchdog (diagnostics.stuckSessionAbortMs) aborts it — by default several minutes later.
Environment
- openclaw 2026.6.1
- Embedded agent run, provider: Google / Gemini (multimodal turn, with grounding)
What happened
A multimodal turn started and emitted no further progress for 381s. The gateway logged it repeatedly as a stalled session, then the watchdog aborted it:
[diagnostic] stalled session: state=processing age=381s queueDepth=2 reason=active_work_without_progress classification=stalled_agent_run activeWorkKind=embedded_run lastProgress=embedded_run:started lastProgressAge=437s recovery=checking
[diagnostic] stuck session recovery: action=abort_embedded_run aborted=true drained=true released=0
Notably, the grounding sub-fetches DID honor a 5s timeout:
[fetch-timeout] fetch timeout after 5000ms (elapsed 5001ms) operation=fetchWithSsrFGuard url=https://vertexaisearch.cloud.google.com/grounding-api-redirect/...
…but the main generation call had no such bound, so the run hung until the coarse watchdog killed it.
Impact
While hung, the run held the session lock; subsequent inbound messages queued (queueDepth=2) and went unprocessed, and the reply was never delivered.
Expected
The model/ACP generation call should have its own bounded, configurable timeout, so a hung provider call fails fast instead of relying solely on the stuck-session watchdog (which defaults to minutes and is a coarse backstop).
Summary
On an embedded agent run, the model generation call appears to have no per-call timeout. When the provider call hangs, the run sits with no progress indefinitely until the stuck-session watchdog (
diagnostics.stuckSessionAbortMs) aborts it — by default several minutes later.Environment
What happened
A multimodal turn started and emitted no further progress for 381s. The gateway logged it repeatedly as a stalled session, then the watchdog aborted it:
Notably, the grounding sub-fetches DID honor a 5s timeout:
…but the main generation call had no such bound, so the run hung until the coarse watchdog killed it.
Impact
While hung, the run held the session lock; subsequent inbound messages queued (
queueDepth=2) and went unprocessed, and the reply was never delivered.Expected
The model/ACP generation call should have its own bounded, configurable timeout, so a hung provider call fails fast instead of relying solely on the stuck-session watchdog (which defaults to minutes and is a coarse backstop).