Summary

When OpenClaw sends a Feishu reply to a message that has already been withdrawn/deleted, the reply call fails and the user gets no response, even though a normal direct send to the same chat would still succeed.

Steps to reproduce

1. Configure a working Feishu account.
2. Trigger an agent reply that targets a specific Feishu message via replyToMessageId.
3. Withdraw or delete the target message before the outbound reply is sent.
4. Let OpenClaw attempt the reply.

Expected behavior

If the reply target no longer exists, OpenClaw should fall back to a normal message send to the same resolved recipient instead of dropping the response.

Actual behavior

Feishu reply delivery fails with a withdrawn/not-found reply-target error, and the agent response is not delivered.

OpenClaw version

main

Operating system

cross-platform

Install method

source build / local checkout

Logs, screenshots, and evidence

Typical Feishu API failures for this path are withdrawn/not-found reply-target errors such as code 230011 (The message was withdrawn.) or 231003 (The message is not found).

Local repro is deterministic with a mocked Feishu client:

• client.im.message.reply(...) returns a withdrawn/not-found error
• client.im.message.create(...) would still succeed for the same recipient
• current sendMessageFeishu / sendCardFeishu stop at the failed reply instead of falling back

Impact and severity

Affected: Feishu users receiving replies to messages that were recalled before delivery completes.
Severity: Medium. The user-visible agent reply is lost.
Frequency: Edge case but deterministic when the target message is withdrawn first.
Consequence: Missing replies in Feishu threads/DMs and confusing silent delivery failures.

Additional information

Root cause is in extensions/feishu/src/send.ts: the reply path treats withdrawn/not-found reply-target errors as terminal, even though the same payload can still be delivered with client.im.message.create(...) using the already-resolved recipient.