openclaw - 💡(How to fix) Fix [Bug]: Session write lock leaked after embedded run timeout during subagent announce

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…

When a subagent completes and announces its result to the parent session, the announce operation acquires the parent session's write lock and triggers an embedded model call. If this embedded run hits the timeoutMs (600000ms in our case), the in-memory session write lock is not released, permanently blocking all subsequent writes to that session within the same process.

This is similar to #49157 but with a specific trigger path: subagent completion → announce → embedded run → timeout → lock leak.

Error Message

[agent/embedded] embedded run timeout: runId=announce:v1:agent:main:subagent:30205c6b-... sessionId=dec68367-... timeoutMs=600000

[diagnostic] lane task error: lane=main durationMs=630254 error="CommandLaneTaskTimeoutError: Command lane "main" task timed out after 630000ms"

[diagnostic] lane task rejected after timeout: lane=main timeoutMs=630000 error="SessionWriteLockTimeoutError: session file locked (timeout 60000ms): pid=1447975 .../dec68367-....jsonl.lock"

From this point on, ALL operations fail:

[warn] Subagent completion direct announce failed for run ...: SessionWriteLockTimeoutError: session file locked (timeout 60000ms) [warn] Subagent announce give up (retry-limit) ... retries=3 endedAgo=73s Embedded agent failed before reply: session file locked (timeout 60000ms)

Root Cause

  • The .lock file itself is deleted after timeout, but the in-memory lock (process-internal HELD_LOCKS map) is never cleared
  • Because PID belongs to the live gateway process, stale-lock detection does not help
  • Only a full gateway restart resolves the deadlock
  • In our PPT workflow, this happens when multiple subagents complete near-simultaneously and their announce operations compete for the same parent session lock

Fix Action

Workaround

Restart the gateway (systemctl --user restart openclaw-gateway-<agent>.service). No configuration change prevents this; it requires a code fix.

Code Example

[agent/embedded] embedded run timeout: runId=announce:v1:agent:main:subagent:30205c6b-... sessionId=dec68367-... timeoutMs=600000

[diagnostic] lane task error: lane=main durationMs=630254 error="CommandLaneTaskTimeoutError: Command lane "main" task timed out after 630000ms"

[diagnostic] lane task rejected after timeout: lane=main timeoutMs=630000 error="SessionWriteLockTimeoutError: session file locked (timeout 60000ms): pid=1447975 .../dec68367-....jsonl.lock"

# From this point on, ALL operations fail:
[warn] Subagent completion direct announce failed for run ...: SessionWriteLockTimeoutError: session file locked (timeout 60000ms)
[warn] Subagent announce give up (retry-limit) ... retries=3 endedAgo=73s
Embedded agent failed before reply: session file locked (timeout 60000ms)

---

try {
  await embeddedRun(...)
} finally {
  releaseSessionWriteLock(sessionId)  // Must happen even on timeout/rejection
}
RAW_BUFFERClick to expand / collapse

[Bug]: Session write lock leaked after embedded run timeout during subagent announce

Environment

  • OpenClaw version: 2026.5.22
  • OS: Linux 6.8.0-1047-aws (x64)
  • Provider: amazon-bedrock (Claude Sonnet 4.6, thinking=adaptive)
  • Channel: Feishu

Description

When a subagent completes and announces its result to the parent session, the announce operation acquires the parent session's write lock and triggers an embedded model call. If this embedded run hits the timeoutMs (600000ms in our case), the in-memory session write lock is not released, permanently blocking all subsequent writes to that session within the same process.

This is similar to #49157 but with a specific trigger path: subagent completion → announce → embedded run → timeout → lock leak.

Steps to Reproduce

  1. Configure agent with thinkingDefault: "adaptive" and multiple subagent spawns (PPT generation workflow with Gen + QA subagents)
  2. Have a long-running parent session with queued messages
  3. When a subagent completes, the announce operation starts an embedded run on the parent session
  4. If the parent session already has queued work or the model call is slow, the announce embedded run hits its timeout
  5. After timeout, the session write lock is never released
  6. All subsequent operations on that session fail with SessionWriteLockTimeoutError indefinitely until gateway restart

Relevant Logs

[agent/embedded] embedded run timeout: runId=announce:v1:agent:main:subagent:30205c6b-... sessionId=dec68367-... timeoutMs=600000

[diagnostic] lane task error: lane=main durationMs=630254 error="CommandLaneTaskTimeoutError: Command lane "main" task timed out after 630000ms"

[diagnostic] lane task rejected after timeout: lane=main timeoutMs=630000 error="SessionWriteLockTimeoutError: session file locked (timeout 60000ms): pid=1447975 .../dec68367-....jsonl.lock"

# From this point on, ALL operations fail:
[warn] Subagent completion direct announce failed for run ...: SessionWriteLockTimeoutError: session file locked (timeout 60000ms)
[warn] Subagent announce give up (retry-limit) ... retries=3 endedAgo=73s
Embedded agent failed before reply: session file locked (timeout 60000ms)

Key Observations

  • The .lock file itself is deleted after timeout, but the in-memory lock (process-internal HELD_LOCKS map) is never cleared
  • Because PID belongs to the live gateway process, stale-lock detection does not help
  • Only a full gateway restart resolves the deadlock
  • In our PPT workflow, this happens when multiple subagents complete near-simultaneously and their announce operations compete for the same parent session lock

Impact

  • Parent session permanently dead until restart (user messages get no response)
  • All pending subagent announces are lost (retry limit = 3, all fail)
  • No automatic recovery mechanism

Expected Behavior

When an embedded run times out, the session write lock should be released in the timeout handler (finally block / cleanup). The lock should never outlive the operation that acquired it.

Suggested Fix

Add lock release to the embedded run timeout/error path:

try {
  await embeddedRun(...)
} finally {
  releaseSessionWriteLock(sessionId)  // Must happen even on timeout/rejection
}

Workaround

Restart the gateway (systemctl --user restart openclaw-gateway-<agent>.service). No configuration change prevents this; it requires a code fix.

Related Issues

  • #49157 (Session write locks leak when Gateway encounters unhandled promise rejections)
  • #75949 (Long LLM turns block incoming system events)
  • #75894 (session-write-lock timeout shorter than legitimate lock holds)

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…

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 - 💡(How to fix) Fix [Bug]: Session write lock leaked after embedded run timeout during subagent announce