#21484: fix(feishu): scope message deduplication by accountId to support multi-bot group

**AI-assisted**: Yes | **Testing**: Fully tested locally ## Summary Describe the problem and fix in 2–5 bullets: - Problem: Multiple Feishu bots configured in the same OpenClaw instance fail to process group chat messages correctly. When a message mentions more than one bot, only the first bot processes it; subsequent bots silently skip the message with "skipping duplicate message" error. - Why it matters: This breaks multi-tenant/multi-bot deployments where users want different agents (main, sub-agents) to handle different Feishu accounts in the same group. - What changed: Modified `src/dedup.ts` and `src/bot.ts` to use a composite key `${accountId}:${messageId}` instead of just `messageId` for deduplication, ensuring each bot maintains its own deduplication state. - What did NOT change (scope boundary): The core Feishu API logic, tool routing, and credential resolution remain untouched. This fix only scopes the in-memory message deduplication cache. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related #16284 (this complements the tool routing fix) ## User-visible / Behavior Changes - In group chats with multiple Feishu bots, all mentioned bots will now respond correctly instead of only the first one. - Log output now includes `(account: <accountId>)` when skipping duplicate messages. None. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: N/A ## Repro + Verification ### Environment - OS: Linux - Runtime/container: OpenClaw Gateway - Model/provider: N/A - Integration/channel (if any): Feishu (multiple accounts) - Relevant config (redacted): Two Feishu accounts configured in `openclaw.json`, both added to the same group chat. ### Steps 1. Configure two Feishu accounts in `openclaw.json` under `channels.feishu.accounts`. 2. Add both Feishu bots to the same group chat. 3. Mention both bots in a single message (e.g., "@BotA @BotB"). 4. Observe that only one bot responds. ### Expected Both bots should respond to their respective mentions. ### Actual Only the first bot responds. The second bot logs: `feishu: skipping duplicate message <messageId>` ### After Fix Both bots respond correctly. The second bot logs: `feishu: skipping duplicate message <messageId> (account: <accountId>)` only if it receives the exact same message ID again (e.g., due to Feishu redelivery), not when processing a fresh message. ## Evidence - [x] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) Log before fix: ``` feishu: skipping duplicate message om_xxx ``` Log after fix (showing correct scoping): ``` feishu: skipping duplicate message om_xxx (account: feishu-2) ``` ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Two Feishu bots in a group chat; mentioning both in one message. - Mentioning only the second bot (should work). - Mentioning only the first bot (should work). - Edge cases checked: - WebSocket reconnection (message redelivery) - should still be deduplicated correctly per bot. - What you did **not** verify: - Performance impact (negligible - simple string concatenation added to existing cache key). ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Revert changes in `src/dedup.ts` (remove `accountId` parameter and composite key logic). - Revert changes in `src/bot.ts` (remove `accountId` argument in `tryRecordMessage` call). - Files/config to restore: - `extensions/feishu/src/dedup.ts` - `extensions/feishu/src/bot.ts` - Known bad symptoms reviewers should watch for: - Messages being processed twice by the same bot (if the composite key logic has a bug). ## Risks and Mitigations - Risk: If `accountId` is undefined/null for some reason, messages might not be deduplicated at all. - Mitigation: Added default value `"default"` to the `accountId` parameter in `tryRecordMessage()` to maintain backward compatibility. - Risk: None. <!-- greptile_comment --> <h3>Greptile Summary</h3> Scopes Feishu message deduplication by `accountId` to enable multiple bots in the same group chat. Previously, the deduplication used only `messageId` as the cache key, causing all bots after the first to skip messages. Now uses composite key `${accountId}:${messageId}` so each bot tracks duplicates independently. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The change is minimal, well-scoped, and correctly implements the composite key pattern for deduplication. The default parameter value provides backward compatibility. The solution directly addresses the multi-bot collision issue without affecting other functionality. - No files require special attention _{Last reviewed commit: 9ea3014} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->