Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix isolated agentTurn cron jobs ignore timeoutSeconds payload setting, capped at ~60s [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59403•Fetched 2026-04-08 02:24:12
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
clawdrjmclawdrjm
Participants
clawdrjmclawdrjmsteipetesteipete
Timeline (top)
referenced ×2closed ×1commented ×1cross-referenced ×1

Error Message

  • Issue #27427 (isolated cron jobs logged as error even when completing)

Fix Action

Workaround

None confirmed. Setting LLM_REQUEST_TIMEOUT=900 in ~/.openclaw/.env appears to raise the cap but this is undocumented and may not be the intended fix.

PR fix notes

PR #59421: fix(cron): propagate timeoutSeconds to LLM idle timeout

Description (problem / solution / changelog)

Fixes #59403

Summary

When a cron job has timeoutSeconds configured (e.g., 900s), the LLM idle timeout was still using the default 60s. This caused jobs to fail prematurely when the LLM took longer than 60s to respond.

Root Cause

The timeoutSeconds cron payload setting only affected the job execution timeout, but the LLM streaming idle timeout (DEFAULT_LLM_IDLE_TIMEOUT_MS = 60_000) was independent.

Solution

If timeoutSeconds is set and llm.idleTimeoutSeconds is not explicitly configured, the cron timeoutSeconds value is now used as the LLM idle timeout.

Before

  • LLM idle timeout always defaulted to 60s
  • Long-running LLM calls would timeout even if timeoutSeconds: 900 was set

After

  • LLM idle timeout respects cron timeoutSeconds when not explicitly configured
  • Users can still override via llm.idleTimeoutSeconds config

Test Plan

  1. Create a cron job with timeoutSeconds: 300
  2. Ensure the LLM has time to complete long responses
  3. Verify no premature timeout at 60s

🤖 Generated with ClawHub

Changed files

  • src/cron/isolated-agent/run.ts (modified, +24/-0)

Code Example

{
  "kind": "agentTurn",
  "message": "..." ,
  "timeoutSeconds": 900
}
RAW_BUFFERClick to expand / collapse

Bug Description

isolated agentTurn cron jobs ignore the timeoutSeconds setting in the job payload. The job is consistently timing out at approximately 60 seconds regardless of the configured value (e.g., timeoutSeconds: 900 is ignored).

Environment

  • OpenClaw version: 2026.4.1 (da64a97)
  • OS: macOS 25.3.0 (arm64)
  • Node: v22.22.0
  • Model provider: minimax-portal (MiniMax-M2.7)
  • Gateway bind: loopback (ws://127.0.0.1:18789)

Steps to Reproduce

  1. Create an isolated agentTurn cron job with a long timeoutSeconds (e.g., 900)
  2. The job does LLM-heavy work that takes 60-90 seconds
  3. Observe: job always errors at ~60s, even though timeoutSeconds is set to 900

Example job payload:

{
  "kind": "agentTurn",
  "message": "..." ,
  "timeoutSeconds": 900
}

Expected Behavior

The timeoutSeconds payload setting should be respected. Jobs that need more than 60s to complete should be allowed to run up to the configured timeout.

Workaround

None confirmed. Setting LLM_REQUEST_TIMEOUT=900 in ~/.openclaw/.env appears to raise the cap but this is undocumented and may not be the intended fix.

Related

  • Issue #42579 (cron lane self-deadlock with maxConcurrentRuns)
  • Issue #27427 (isolated cron jobs logged as error even when completing)
  • Issue #17519 (cron API websocket timeout at 60s — possibly related)

extent analysis

TL;DR

Setting the LLM_REQUEST_TIMEOUT environment variable to the desired timeout value may allow isolated agentTurn cron jobs to respect the timeoutSeconds setting in the job payload.

Guidance

  • Investigate the relationship between the timeoutSeconds payload setting and the LLM_REQUEST_TIMEOUT environment variable to determine if they are related.
  • Test setting LLM_REQUEST_TIMEOUT to a value higher than 60 seconds (e.g., 900) to see if it allows jobs to run for the configured timeout.
  • Review related issues (e.g., #17519) to determine if the 60-second timeout is a known limitation of the cron API websocket.
  • Verify that setting LLM_REQUEST_TIMEOUT does not introduce unintended side effects, such as affecting other types of jobs or system performance.

Example

No code snippet is provided as the issue is related to configuration and environment variables.

Notes

The effectiveness of setting LLM_REQUEST_TIMEOUT is uncertain, as it is an undocumented fix. Additionally, the relationship between this variable and the timeoutSeconds payload setting is not clear.

Recommendation

Apply workaround: Set LLM_REQUEST_TIMEOUT to the desired timeout value, as it may allow isolated agentTurn cron jobs to respect the timeoutSeconds setting, although its impact on the system is not fully understood.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#logging issue#authentication issue#prompt issue#agent setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix isolated agentTurn cron jobs ignore timeoutSeconds payload setting, capped at ~60s [1 pull requests, 1 comments, 2 participants]