openclaw - 💡(How to fix) Fix [Bug]: EmbeddedAttemptSessionTakeoverError causes silent message loss when session lock is released during API retries

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When a model API (e.g., DeepSeek) experiences consecutive ECONNRESET errors, the gateway retries the request. During retries, the embedded prompt lock on the session file is released. If another message queues up and modifies the session file during this window, the original attempt detects a fingerprint mismatch and throws EmbeddedAttemptSessionTakeoverError:

session file changed while embedded prompt lock was released This causes the reply to be silently dropped — the control panel shows a reply was generated, but the message never reaches the user (e.g., via Feishu). The gateway eventually falls back to a generic "⚠️ Something went wrong…" message, but the original reply is lost.

Steps to reproduce

1. Have a model provider that intermittently returns ECONNRESET/timeout
2. Start a conversation turn (embedded agent attempt acquires session lock)
3. API fails → lock releases during retry → another incoming message modifies session file → original attempt resumes and detects fingerprint mismatch
4. EmbeddedAttemptSessionTakeoverError is thrown, reply is never delivered

Expected behavior

The session lock should either:

1. Automatically retry (with backoff) when takeover is detected, OR
2. Queue the reply for later delivery instead of silently dropping it

Actual behavior

• Message silently lost (no delivery to chat channel)
• Can be delayed by days (message reappears after gateway restart)
• Often accompanied by Feishu API 502 errors (separate issue)

OpenClaw version

2026.5.22

Operating system

macOS 14.6.1

Install method

No response

Model

deepseek-v4-pro

Provider / routing chain

openclaw-deepseek

Additional provider/model setup details

The noopLock fallback in the current implementation (return noopLock) effectively discards the lock acquisition — there's no retry logic or graceful degradation. A simple retry loop (e.g., 3 attempts with exponential backoff) would significantly reduce message loss.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response