openclaw - 💡(How to fix) Fix Session file write lock not released after background turn maintenance (SessionWriteLockTimeoutError)

Description

After a successful agent reply, the session file write lock is not always released by background maintenance tasks (LCM deferred turn maintenance / auto-rotate / compaction). When a new message arrives, it hits SessionWriteLockTimeoutError because the lock is still held by the same gateway process.

Symptoms

lane task error: lane=main durationMs=63092 error="SessionWriteLockTimeoutError: session file locked (timeout 60000ms): pid=400649 /.../sessions/xxx.jsonl.lock"
Embedded agent failed before reply: session file locked (timeout 60000ms): pid=400649 /.../sessions/xxx.jsonl.lock
feishu[default]: dispatch complete (queuedFinal=false, replies=0)

Lock file metadata:

{"pid": 400649, "createdAt": "...", "maxHoldMs": 1020000, "starttime": ...}

• Lock is created during turn maintenance phase after a successful reply
• maxHoldMs: 1020000 (17 minutes timeout)
• The lock is not released when the background maintenance task completes or fails
• Subsequent messages fail to write to the session file (60s write lock timeout)
• Agent fails to reply (replies=0)

Environment

• OpenClaw version: v2026.5.24-beta.1 (ea685a7)
• Node: v24.15.0
• OS: WSL2 (Ubuntu)
• Channel: Feishu (WebSocket)
• Plugins: lossless-claw, memory-core, memory-wiki, openclaw-lark

Sequence

1. User sends message → agent dispatches → agent replies successfully → lock released ✓
2. Background turn maintenance (LCM auto-rotate/assemble) runs and acquires session write lock
3. Maintenance task completes but write lock is not released (stale)
4. New user message arrives → agent tries to write to session file → SessionWriteLockTimeoutError after 60s timeout
5. Agent fails with replies=0

Workaround

Restart the gateway process.

Expected behavior

Background maintenance tasks should always release the session write lock after completion, even if they encounter errors or edge cases during the write phase.