openclaw - 💡(How to fix) Fix Feishu side-path send can succeed while inbound turn still closes as replies=0 [1 comments, 2 participants]

Summary

Feishu/Lark inbound turns can complete with replies=0 even when a same-turn side-path outbound send clearly succeeded.

This creates a reply-accounting mismatch: the user-visible send path fires, but the inbound turn is still classified like a no-reply turn.

Environment

• OpenClaw gateway: v2026.4.29
• Plugin: local openclaw-lark
• Feishu mode: websocket
• Reproduced in real group chats, not synthetic test only

Confirmed symptom

For Feishu group turn:

• handleAction: action=send
• deliverMessage: type=text, target=<chatId>
• sendTextLark: target=<chatId>
• deliverMessage: text sent, messageId=<outboundMessageId>

all occur successfully in the same inbound turn, but later the same inbound turn logs:

• dispatch complete (replies=0, sidePathSends=1, elapsed=...)

This means the plugin/runtime knows an outbound side-path send happened, but inbound closure accounting still treats the turn as replies=0.

Reproduction evidence

Case A: side-path send happened but closure still says replies=0

Chat:

• oc_5cc1621461880ae8dccec0147e40896b

Inbound message id:

• om_x100b5096713f50a0c45fd5fe8b7d814

Observed log chain:

• feishu[default][msg:om_x100b5096713f50a0c45fd5fe8b7d814]: handleAction: action=send, accountId=default
• feishu[default][msg:om_x100b5096713f50a0c45fd5fe8b7d814]: deliverMessage: type=text, target=oc_5cc1621461880ae8dccec0147e40896b, ...
• feishu[default][msg:om_x100b5096713f50a0c45fd5fe8b7d814]: sendTextLark: target=oc_5cc1621461880ae8dccec0147e40896b, textLength=213
• feishu[default][msg:om_x100b5096713f50a0c45fd5fe8b7d814]: deliverMessage: text sent, messageId=om_x100b50960f1f1ca0c3cbfb30d31704e
• feishu[default][msg:om_x100b5096713f50a0c45fd5fe8b7d814]: dispatch complete (replies=0, sidePathSends=1, elapsed=47524ms)

Channel-level companion log:

• dispatch complete (queuedFinal=false, replies=0, sidePathSends=1, sidePathLastMessageId=om_x100b50960f1f1ca0c3cbfb30d31704e)

This is the core bug.

Case B: distinct no-reply path (not the same bug class)

Chat:

• oc_80377304b21bdd970599c79d13a45f9b

Inbound message id:

• om_x100b5096340128a4c4c049ee0cce5d1

Observed completion:

• dispatch complete (replies=0, sidePathSends=0, elapsed=101029ms)

This shows a separate no-reply/no-side-path class and helps distinguish the accounting mismatch from other Feishu reply failures.

Why this matters

The runtime currently conflates at least two different states:

1. true no-reply turn
2. side-path-satisfied turn where an outbound send succeeded outside dispatcher-managed final reply counting

That makes:

• diagnostics misleading
• governance / retry logic harder
• user-visible success disagree with runtime closure state

Expected behavior

When a same-turn side-path send succeeds and is clearly associated with the current inbound turn, the runtime should expose a distinct closure/accounting state rather than collapsing it into plain replies=0.

I am not asserting the exact API shape, but at minimum the runtime/plugin should distinguish:

• true no-reply
• side-path-satisfied turn

Notes

This does not look like a pure Feishu transport failure:

• the outbound send path logs success
• a concrete outbound message id is returned
• the inconsistency is in inbound turn closure/accounting

A separate investigation is ongoing for restart/load semantics of local plugin changes, but that is not required to see this accounting mismatch itself.