Environment
- ZCode desktop app, macOS (arm64), built-in bot integration, provider =
lark, Lark long-connection (WebSocket) event subscription
Observed behavior
The bot runtime deduplicates fast re-pushes that reuse the same Lark message_id (visible in logs as provider callback duplicated) — this works well.
However, the same user message is sometimes delivered again minutes to hours later carrying a new message_id. It passes the messageId-level dedup and is dispatched to the agent session as a fresh user message, so the assistant answers the same question multiple times. Worst case observed: original at 13:40, ghost redelivery at 19:40 (≈6h gap). Sanitized logs:
# class 1: fast re-push, same message_id -> caught
[bots] provider callback provider=lark ... text=<user message>
[bots] provider callback duplicated provider=lark ... messageId=om_xxxx
# class 2: slow redelivery, new message_id -> dispatched again (not flagged)
[13:40:24] provider callback provider=lark ... text=<same user message>
[19:40:29] provider callback provider=lark ... text=<same user message> # new om_ id
Possible causes
- Lark guarantees at-least-once event delivery; server-side retry/replay after WS reconnects
- Sender-side (mobile client) resends on flaky networks can create genuinely new message events (new message_id)
Suggestion
- In addition to the existing
message_id dedup, add a second layer keyed by (user_id + normalized content fingerprint) with a long window (e.g., 24h) to absorb slow redeliveries
- Ensure WS reconnect/replay paths go through the same dedup cache
Environment
lark, Lark long-connection (WebSocket) event subscriptionObserved behavior
The bot runtime deduplicates fast re-pushes that reuse the same Lark
message_id(visible in logs asprovider callback duplicated) — this works well.However, the same user message is sometimes delivered again minutes to hours later carrying a new
message_id. It passes the messageId-level dedup and is dispatched to the agent session as a fresh user message, so the assistant answers the same question multiple times. Worst case observed: original at 13:40, ghost redelivery at 19:40 (≈6h gap). Sanitized logs:Possible causes
Suggestion
message_iddedup, add a second layer keyed by(user_id + normalized content fingerprint)with a long window (e.g., 24h) to absorb slow redeliveries