Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Lane timeout hardcoded at 630s — independent from agents.defaults.timeoutSeconds config [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#77741•Fetched 2026-05-06 06:22:07
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
2
Author
slideshow-dingoslideshow-dingo
Participants
clawsweeper[bot]clawsweeper[bot]slideshow-dingoslideshow-dingo
Timeline (top)
closed ×1commented ×1cross-referenced ×1

The gateway's command lane system uses a hardcoded 630-second (10.5 minute) timeout for lane task execution, defined in the source code. This is separate from and ignores the user-configurable agents.defaults.timeoutSeconds setting.

Root Cause

In src/process/command-queue.ts, the lane task timeout is hardcoded:

const LANE_TASK_TIMEOUT_MS = 630000; // 10.5 minutes

This value is not exposed to configuration and does not respect agents.defaults.timeoutSeconds.

Fix Action

Workaround

None — requires gateway restart to clear stuck lanes before the 630s timeout fires.

Code Example

const LANE_TASK_TIMEOUT_MS = 630000; // 10.5 minutes
RAW_BUFFERClick to expand / collapse

Summary

The gateway's command lane system uses a hardcoded 630-second (10.5 minute) timeout for lane task execution, defined in the source code. This is separate from and ignores the user-configurable agents.defaults.timeoutSeconds setting.

Impact

When a session lane becomes stuck (e.g., hung promise, unresponsive model API, compaction deadlock), the lane remains blocked for up to 630 seconds before timing out — regardless of the configured timeout. This causes:

  1. Prolonged gateway unresponsiveness — single stuck lane blocks all messages for that session for 10+ minutes
  2. Cascading queue buildup — subsequent messages queue behind the stuck task
  3. No graceful degradation — gateway appears healthy but cannot process messages
  4. Event loop starvation — stuck lanes contribute to sustained high event loop delay (ELD P99 > 5000ms)

Root Cause

In src/process/command-queue.ts, the lane task timeout is hardcoded:

const LANE_TASK_TIMEOUT_MS = 630000; // 10.5 minutes

This value is not exposed to configuration and does not respect agents.defaults.timeoutSeconds.

Expected Behavior

  1. Lane task timeout should be configurable via config schema (e.g., gateway.laneTimeoutSeconds or inherit from agents.defaults.timeoutSeconds)
  2. Sensible default should be much lower (e.g., 120-180s) to fail fast and trigger recovery
  3. Timeout expiration should clear the lane state and allow subsequent messages to proceed

Workaround

None — requires gateway restart to clear stuck lanes before the 630s timeout fires.

Related

  • #48488 (Lane queue has no task-level timeout — hung promises permanently block session lanes)
  • #70334 (Session lock stuck in 'processing' after context overflow compaction succeeds)
  • #76467 (Gateway becomes completely unresponsive after compaction triggers)
  • #77115 (Stuck session ghost blocks event loop, causes CLI timeout and sustained high CPU)

Environment

  • OpenClaw 2026.5.3
  • Observed in production ghosting incident 2026-05-05

extent analysis

TL;DR

The hardcoded 630-second lane task timeout in the gateway's command lane system should be made configurable to prevent prolonged unresponsiveness and cascading queue buildup.

Guidance

  • Identify the LANE_TASK_TIMEOUT_MS constant in src/process/command-queue.ts and consider replacing it with a configurable value, such as gateway.laneTimeoutSeconds or inheriting from agents.defaults.timeoutSeconds.
  • Evaluate the current timeout value (10.5 minutes) and consider reducing it to a lower value (e.g., 120-180s) to fail fast and trigger recovery.
  • Review related issues (#48488, #70334, #76467, #77115) to understand the broader impact of stuck lanes on the gateway's performance and event loop delay.
  • Consider implementing a mechanism to clear the lane state upon timeout expiration, allowing subsequent messages to proceed.

Example

// Example of making the lane task timeout configurable
const laneTimeoutMs = config.gateway.laneTimeoutSeconds * 1000;

Notes

The provided workaround requires a gateway restart to clear stuck lanes, which may not be feasible in production environments. Making the lane task timeout configurable and reducing its value can help mitigate the issue, but further investigation into the related issues may be necessary to fully resolve the problem.

Recommendation

Apply a workaround by making the lane task timeout configurable and reducing its value, as this will help prevent prolonged unresponsiveness and cascading queue buildup, and allow for more graceful degradation and recovery.

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#prompt issue#agent setup#task chaining#parallel task

Still need to ship something?

×6

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

Back to top recommendations

TRENDING