OpenClaw merged PR #96100, "fix(agent): replace self-wait with deferred release in retained-lock abort cleanup", a P1 agent-runtime fix for a nasty session-lock failure mode.
The bug affected embedded agent runs that timed out or aborted while an active retained session write was still in progress. In that state, OpenClaw could fail to release the held write lock immediately. The lock would remain until a watchdog timer fired, which the PR describes as a 90- to 350-second delay depending on the path.
For operators, that kind of bug looks like an agent that should have failed fast but instead leaves the session temporarily wedged.
The Failure Mode
The PR explains the root cause in the retained session write-lock cleanup path. When abort cleanup tried to release a held lock while the active write scope was still alive, the release path could not safely complete. A previous attempted fix added a wait inside the active scope, but that created a self-deadlock: the code waited for a retained-use count to drop while still running inside the scope that needed to unwind.
That is a subtle concurrency problem, and it is exactly why this PR carries both P1 and merge-risk labels for session state and availability.
The user-visible impact was simpler than the internals. After an embedded run timed out, follow-up turns on the same session could run into stale lock behavior or timeout symptoms until the watchdog cleaned up.
What Changed
The new fix avoids waiting on itself. Instead of trying to complete the release while the active scope is still alive, OpenClaw now marks the held lock for deferred release. Once the write scope has deactivated and retained use is released, the cleanup path retries the release at a point where waiting is safe.
The PR adds regression coverage for three important cases:
- Deferred release after an active scope
- Abort, reacquire, and release across a full lifecycle
- Avoiding self-deadlock when cleanup is requested from inside the active scope
That combination is the right shape for a concurrency fix. It tests not only the happy path but the timing-sensitive paths that made the original bug difficult.
Why This Matters
OpenClaw sessions are durable state. If an agent run fails, the next run should be able to recover cleanly instead of inheriting a lock left behind by the failure path.
This is especially important for embedded runs, scheduled automation, and channel-delivered work where a human may not be watching the terminal when a timeout occurs. A leaked session write lock can turn a single bad run into a longer outage for that conversation.
PR #96100 gives OpenClaw a cleaner failure boundary: aborts can still happen, but the session write lock should not remain stuck until a watchdog intervenes.
Verification
The PR reports 108 focused session-lock tests, type checks, and a successful build. It also includes live runtime proof from a Linux environment where an embedded agent run was forced to timeout during an active provider stream. After the fix, the author reported no stale .jsonl.lock files and no session write-lock timeout errors in the runtime log.
That is the important operational result: the run can abort, the error can surface, and the session can still be ready for the next turn.