Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: cron timeout not work [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#59133•Fetched 2026-04-08 02:28:16
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
zeerdzeerd
Participants
steipetesteipetezeerdzeerd
Timeline (top)
labeled ×2closed ×1commented ×1cross-referenced ×1

After upgrade from 2026.3.28 to 2026.3.31, the time out of cron not work but using the agents.defaults.timeoutSeconds.

Root Cause

After upgrade from 2026.3.28 to 2026.3.31, the time out of cron not work but using the agents.defaults.timeoutSeconds.

Fix Action

Fixed

PR fix notes

PR #59432: fix: distinguish LLM idle timeout from request timeout in error message (#59133)

Description (problem / solution / changelog)

Summary

Fixes #59133 — cron timeout appears not to work after upgrading to 2026.3.31.

Root cause

The new LLM idle timeout feature (added between 3.28 and 3.31) introduces a 60-second default idle timeout that fires if no token is received from the model during streaming. For slow local models (e.g., Ollama running large quantized models), this idle timeout fires before the cron job's configured timeoutSeconds (e.g., 120s), aborting the request.

The error message misleadingly tells users to increase agents.defaults.timeoutSeconds, but the actual timeout that fired is the LLM idle timeout, which is configured via agents.defaults.llm.idleTimeoutSeconds.

Changes

  • Add idleTimedOut flag to EmbeddedRunAttemptResult to track whether the abort was caused by the LLM idle timeout specifically
  • Set the flag in the idle timeout trigger callback in attempt.ts
  • Update the timeout error message in run.ts to suggest the correct config key:
    • Idle timeout → suggests agents.defaults.llm.idleTimeoutSeconds (set to 0 to disable)
    • General timeout → suggests agents.defaults.timeoutSeconds (existing behavior)
  • Update all test fixtures that construct EmbeddedRunAttemptResult to include the new field

Verification

  • pnpm check passes clean
  • pnpm test -- src/agents/pi-embedded-runner/run/llm-idle-timeout.test.ts — all 14 tests pass

Changed files

  • src/agents/pi-embedded-runner.run-embedded-pi-agent.auth-profile-rotation.e2e.test.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/run.overflow-compaction.fixture.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +7/-3)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +3/-0)
  • src/agents/pi-embedded-runner/run/types.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner/usage-reporting.test.ts (modified, +1/-0)
  • src/agents/test-helpers/pi-embedded-runner-e2e-fixtures.ts (modified, +1/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrade from 2026.3.28 to 2026.3.31, the time out of cron not work but using the agents.defaults.timeoutSeconds.

Steps to reproduce

Run any cron task with timeout setting to 120s which is more than 60 seconds.

Expected behavior

timeout of cron works.

Actual behavior

Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

OpenClaw version

2026.3.31

Operating system

Ubuntu 24.04

Install method

docker

Model

local-ollama-qwen3.5:35b

Provider / routing chain

local ollama by docker

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The cron task timeout may not be working as expected due to a potential issue with the agents.defaults.timeoutSeconds configuration after the upgrade to version 2026.3.31.

Guidance

  • Verify that the agents.defaults.timeoutSeconds value is being correctly set and applied to the cron tasks, as the error message suggests that this value is being used instead of the task-specific timeout.
  • Check the configuration files or environment variables to ensure that the agents.defaults.timeoutSeconds value is not being overridden or reset to a lower value (e.g., 60 seconds).
  • Test the cron task with a timeout setting lower than 60 seconds to see if the issue is specific to timeouts greater than 60 seconds.
  • Review the release notes for version 2026.3.31 to see if there are any known issues or changes related to cron task timeouts or the agents.defaults.timeoutSeconds configuration.

Notes

The issue may be specific to the upgrade from 2026.3.28 to 2026.3.31, and the root cause is unclear without more information about the configuration and environment.

Recommendation

Apply workaround: increase the agents.defaults.timeoutSeconds value in the config to a value greater than 120 seconds to see if it resolves the issue, as this may indicate a problem with the task-specific timeout setting being overridden.

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…

FAQ

Expected behavior

timeout of cron works.

#request error#file not found#serialization error#model compatibility#GPU 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