Summary

• Problem: Issue [Bug]: Session write lock leaked after embedded run timeout during subagent announce #86816 reports that when a subagent completes and triggers an announce embedded run on the parent session, hitting the embedded-run timeoutMs (600000ms in the reporter's environment) leaves the session write lock pinned in memory. All subsequent writes to that session fail with SessionWriteLockTimeoutError until the gateway is restarted. Subagent announce retries (limit 3) all fail; the user sees no response on Feishu.
• Root Cause: runEmbeddedAttempt already releases the session write lock from its outer finally (releaseRetainedSessionLock?.() at src/agents/pi-embedded-runner/run/attempt.ts, shipped in SessionWriteLockTimeoutError: gateway never releases session file lock after embedded run timeout #86014/fix(agents): release embedded-attempt session lock on every exit path #86427), and the in-process session-write-lock module already runs a watchdog that force-releases held locks after maxHoldMs. Both safety nets exist. The remaining gap: when the embedded-run timeout fires (scheduleAbortTimer → abortRun(true) in src/agents/pi-embedded-runner/run/attempt.ts), the inner stream / model call can fail to observe the abort signal and never unwind, so runEmbeddedAttempt never returns and the outer finally never runs. The watchdog still cleans the lock, but its window for the announce-style embedded attempt is compactionTimeoutMs + 120s grace ≈ 17 min — too long for a user-facing chat bot. Operators restart the gateway well before the watchdog reclaims the lock, so from the user's view the lock is leaked "permanently until restart" (matching the issue's exact wording).
• Fix: Add one branch to abortRun in src/agents/pi-embedded-runner/run/attempt.ts that, on the isTimeout === true path, calls sessionLockController.releaseHeldLockForAbort() immediately after the abort signal goes out. The helper already exists at src/agents/pi-embedded-runner/run/attempt.session-lock.ts (used by the sessions_yield abort cleanup path) and is idempotent: it early-returns when heldLock is already cleared. The outer finally's dispose() remains the canonical release path; this new branch shrinks the leak window from ~17 min (watchdog) to immediate.
• What changed:
  • src/agents/pi-embedded-runner/run/attempt.ts — abortRun(isTimeout=true, ...) now calls void sessionLockController.releaseHeldLockForAbort().catch(log.warn) after the abort signal. Branch is gated on isTimeout === true so manual cancel and non-timeout abort paths continue to rely on the outer finally.
  • src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts — new test releaseHeldLockForAbort + dispose() are idempotent in succession (#86816) pins the idempotency contract the fix relies on.
• What did NOT change (scope boundary):
  • src/agents/pi-embedded-runner/run/attempt.session-lock.ts — controller API surface (releaseHeldLockForAbort, dispose) untouched; the fix reuses the existing helper.
  • src/agents/session-write-lock.ts — file-lock acquire/release/watchdog logic untouched.
  • Manual-cancel (non-timeout) abort path — still routes through the outer finally only. No change to abortRun(false, ...) semantics.
  • The watchdog continues to be the fallback for any path that bypasses both the outer finally and this new branch.
  • Config surface unchanged (no schema, defaults, doctor migrations, or docs/reference/config edits).
  • Plugin surface unchanged (no plugin SDK, manifest, extensions/api.ts / runtime-api.ts, registry, or loader edits).
  • Session store surface unchanged (no sessions.json format, transcript jsonl format, or store-loader edits — relevant given the June SQLite migration).

Reproduction

1. On 2026.5.22, configure an agent with thinkingDefault: "adaptive" plus multiple subagent spawns (PPT generation, QA workflows).
2. Have a long-running parent session with queued messages.
3. A subagent completes; the announce flow starts an embedded run on the parent session.
4. The model call hangs or runs past 600000ms.
5. Before this PR: the abort signal fires but the inner stream does not observe it; runEmbeddedAttempt never returns; outer finally never runs; session write lock stays pinned in memory; all subsequent session writes fail with SessionWriteLockTimeoutError for ~17 min (until the watchdog) — operators restart the gateway in the meantime, so the lock looks permanent.
6. After this PR: when the timeout aborts the run, abortRun(true, ...) calls releaseHeldLockForAbort() immediately, the session write lock is released, and the next subagent announce / inbound message succeeds without waiting for the watchdog or a restart.

Real behavior proof

Behavior addressed (#86816): session write lock is released as soon as a timeout aborts a runEmbeddedAttempt, even when the inner stream does not observe the abort and runEmbeddedAttempt never returns; non-timeout abort paths and the outer finally's dispose() remain canonical.

Real environment tested (Linux, Node 22, real-component tsx harness driving production session-write-lock + createEmbeddedAttemptSessionLockController): tsx-resolved imports of production acquireSessionWriteLock, createEmbeddedAttemptSessionLockController, and isSessionWriteLockTimeoutError. The harness mirrors the abortRun call-sequence by creating a real controller, then for each scenario either calling or omitting releaseHeldLockForAbort(), and probing the lock state via same-process re-acquire with a 1.5s timeout.

Exact steps or command run after this patch:

1. node_modules/.bin/tsx /tmp/qmd86816/repro.mts (real-component BEFORE/AFTER lock-state sweep)
2. node scripts/run-vitest.mjs src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts
3. pnpm exec oxfmt --check --threads=1 src/agents/pi-embedded-runner/run/attempt.ts src/agents/pi-embedded-runner/run/attempt.session-lock.test.ts

Evidence after fix (verbatim real-component harness output):

================ #86816 real-component lock-leak BEFORE/AFTER sweep ================

Drives production createEmbeddedAttemptSessionLockController + acquireSessionWriteLock.

--- SCENARIO A: BEFORE FIX (abortRun(true) does NOT release lock) ---
  controllerA created (heldLock acquired)
  simulating abortRun(true) without lock-release call...
  same-process re-acquire (1.5s timeout): held=true (1505ms)
  >>> BEFORE FIX RESULT: lock LEAKED (matches issue #86816 — gateway dead until watchdog ~17min or restart)

--- SCENARIO B: AFTER FIX (abortRun(true) calls releaseHeldLockForAbort) ---
  controllerB created (heldLock acquired)
  simulating abortRun(true) WITH lock-release call...
  same-process re-acquire (1.5s timeout): held=false (3ms)
  >>> AFTER FIX RESULT: lock released (matches expected — gateway recovers immediately)
  controllerB.dispose() called (idempotent — should be safe even after release-on-abort)

--- SCENARIO C: non-timeout abort (isTimeout=false) NOT affected ---
  controllerC created (heldLock acquired)
  simulating abortRun(false) — manual cancel, NOT timeout...
  same-process re-acquire (1.5s timeout): held=true (1505ms)
  >>> SAFETY: manual-cancel path lock still held (correct — outer-finally is responsible)

================ VERDICT ================
Scenario A (BEFORE FIX, timeout abort):  lock leaked = true  OK
Scenario B (AFTER FIX, timeout abort):   lock leaked = false  OK
Scenario C (manual cancel, not timeout): lock leaked = true  OK (outer-finally owns it)

PASS — fix changes timeout-abort behavior; non-timeout abort behavior preserved.

Vitest output for the touched test file:

 RUN  v4.1.7 /root/main/openclaw/.worktrees/pr-87107

 Test Files  2 passed (2)
      Tests  78 passed (78)
   Duration  7.91s

Observed result after fix:

• Timeout-aborted embedded runs release the session write lock immediately (3ms in the harness vs the 1505ms re-acquire timeout BEFORE fix).
• Manual-cancel abort (isTimeout === false) continues to rely on the outer finally and the watchdog — no behavioral change for that path (Scenario C).
• The new releaseHeldLockForAbort + dispose() are idempotent in succession (#86816) test verifies that the outer finally's dispose() remains a safe no-op when the lock has already been released by the timeout branch.

What was not tested:

• End-to-end live Feishu / PPT-workflow subagent announce. The real-component harness drives the production lock controller and lock helpers end-to-end but does not start a real announce / model HTTP call. The bug's necessary conditions (controller + abort + missing release) are reproduced deterministically.
• Watchdog interaction (runLockWatchdogCheck) — the fix bypasses the watchdog for the timeout path; the watchdog continues to be the safety net for any future code path that bypasses both the outer finally and this new branch.
• Other acquireSessionWriteLock callers (src/agents/command/attempt-execution.ts, src/agents/pi-embedded-runner/tool-result-truncation.ts, src/agents/sandbox/registry.ts) — these are short-hold acquires with their own try/finally; not part of the announce-embedded-run hang scenario.

Regression tests:

• attempt.session-lock.test.ts → new releaseHeldLockForAbort + dispose() are idempotent in succession (#86816) test plus the preserved defensively releases the coarse attempt lock on sessions_yield abort cleanup and keeps the session fence active after releasing for sessions_yield abort cleanup tests pin the controller-level contract this PR relies on.

Risk / Mitigation

• Risk: releaseHeldLockForAbort() is called eagerly before the inner stream unwinds; any inner withSessionWriteLock that has captured the lock by reference could in theory race with the new release. Mitigation: a late-arriving inner write is protected by the fence/takeover mechanism — releaseHeldLockWithFence sets fenceActive = true before lock.release(), so any subsequent withSessionWriteLock reacquires fresh via acquireLock() and then assertSessionFileFence() throws EmbeddedAttemptSessionTakeoverError if the file fingerprint changed under it. Separately, same-process double-release is impossible because controller.acquireWriteLock() returns { lock, owned: false } when the call shares the controller's heldLock, and the inner withSessionWriteLock's finally only releases when owned === true.
• Risk: The fix only addresses the isTimeout === true branch. A non-timeout abort that hangs the inner stream would still leak the lock until the watchdog reclaims it. Mitigation: non-timeout aborts are user-initiated cancellations and follow a different lifecycle (the outer finally is reached because the caller awaits and unwinds normally). The watchdog continues to be the fallback. Adding the same release call to the non-timeout branch was considered but deferred — it would broaden the scope without a reported regression.
• Risk: Calling releaseHeldLockForAbort() from abortRun could surface a previously-hidden double-release error path. Mitigation: pinned by the new idempotency test (releaseHeldLockForAbort + dispose() called four times in succession with one acquire and one release expected).
• Risk: The fix lives in src/agents/pi-embedded-runner/run/attempt.ts, an active area. Mitigation: change is 13 lines, additive, gated on isTimeout === true, uses an existing controller method already exercised by the sessions_yield abort cleanup path. Recent main commits on pi-embedded-runner (cc704caa08, 1710dac5eb, 8c644ee611) confirm the module is under active maintenance.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Sessions / storage

Linked Issue/PR

Fixes #86816