Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On 2026.6.11, when reply dispatch fails with "reply session initialization conflicted", the Feishu account handler only logs the error and drops the inbound message — the sender gets no reply and no notice (15 occurrences in 8 days on our production gateway).

Steps to reproduce

1. Run an OpenClaw 2026.6.11 gateway (systemd user service) with the Feishu channel in websocket mode.
2. In a Feishu DM: send /new, then send an image message, and wait for the reply turn to complete.
3. Within ~60s, send a follow-up text message.
4. Intermittently (15 times in 8 days on our gateway), dispatch fails with reply session initialization conflicted after session-init retries are exhausted; the inbound message is dropped with no user-visible feedback and no channel-level retry.

Expected behavior

Parity with other channels for this exact error: Slack (#99647) and Signal (#100944, fixed via #103218) special-case "reply session initialization conflicted" with bounded retry + backoff, and Telegram spools the update for delayed replay. The Feishu channel should retry the dispatch and/or send the user a visible failure notice instead of losing the message.

Actual behavior

The catch block at the end of handleFeishuMessage (extensions/feishu) only logs feishu[default]: failed to dispatch message: Error: reply session initialization conflicted for <sessionKey> and returns. No retry, no spool, no user notice — the inbound message is permanently lost and the sender perceives the bot as unresponsive. Verified in gateway journal logs (excerpt below).

OpenClaw version

2026.6.11 (e085fa1)

Operating system

Ubuntu 24.04.3 LTS (Node v22.22.2, systemd user service)

Install method

npm global (user-level prefix ~/.local)

Model

deepseek/deepseek-v4-pro-202606

Provider / routing chain

openclaw -> deepseek (openai-completions endpoint)

Additional provider/model setup details

Bug is channel-side (Feishu dispatch error handling); it reproduces regardless of the model provider. Provider transport logs show the model call is never made for the dropped message.

Logs

Redacted journalctl excerpt (openclaw-gateway, 2026-07-15, +08:00):


20:32:34 [feishu] feishu[default]: received message from ou_REDACTED in oc_REDACTED (p2p)
20:32:34 [feishu] feishu[default]: dispatching to agent (session=agent:feishu-ou_REDACTED:main)
20:32:38 [diagnostic] message dispatch completed: channel=feishu sessionId=unknown sessionKey=agent:feishu-ou_REDACTED:main source=replyResolver outcome=error duration=3775ms error="Error: reply session initialization conflicted for agent:feishu-ou_REDACTED:main"
20:32:38 [diagnostic] message processed: channel=feishu chatId=user:ou_REDACTED messageId=om_REDACTED sessionId=REDACTED sessionKey=agent:feishu-ou_REDACTED:main outcome=error duration=3780ms error="Error: reply session initialization conflicted for agent:feishu-ou_REDACTED:main"
20:32:38 [feishu] feishu[default]: failed to dispatch message: Error: reply session initialization conflicted for agent:feishu-ou_REDACTED:main


The next inbound message 18s later (an image) failed the same way; the one after that succeeded. 15 such incidents between Jul 8 and Jul 15 (`journalctl | grep -c "initialization conflicted"` = 45 lines / 3 per incident).

Screenshots, recordings, and evidence

Text logs above are the primary evidence. A user-side screenshot shows the dropped DM with no bot response (can attach on request; it contains user PII so omitted by default).

Impact and severity

Affected: all Feishu users on the gateway (11 registered users on ours; DM and group sessions share the code path)
Severity: high — inbound user messages are lost silently; users believe the bot is down
Frequency: intermittent; 15 incidents in 8 days (Jul 8–15), sometimes 2 consecutive messages dropped
Consequence: message loss with no feedback, no retry, no operator alert; trust damage in production

Additional information

Related issues: #99500 (feishu, closed as not planned — framed as self-resolving; in our case the user's inbound message is permanently lost and only a manual resend recovers), #100944 (Signal, same silent-drop pattern, fixed in #103218), #99647 (Slack retry), #96837 (Telegram spool), #96847 (serializes session init; merged after 2026.6.11).

Additional observation: in our incidents the init-conflict persisted across the whole retry window (~3.8s) while the session store file mtime did not change, i.e. the conflict was not caused by a concurrent external write. Disabling the session store cache (OPENCLAW_SESSION_CACHE_TTL_MS=0) eliminated the conflicts on our gateway, which suggests a writer-cache/disk divergence on 2026.6.11 (possibly already addressed by #96847). Regardless of the root cause, the Feishu channel should not lose the message silently — that is the ask here.

Local workaround we applied: OPENCLAW_SESSION_CACHE_TTL_MS=0 + a patched catch block in the Feishu handler that sends the sender a "message not processed, please resend" notice.