Skip to content

[Bug]: EmbeddedAttemptSessionTakeoverError causes silent message loss when session lock is released during API retries #87180

Description

@vchenyang

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.bugSomething isn't workingbug:behaviorIncorrect behavior without a crashclawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions