PR #75078: fix(feishu): media-aware dedupe key prevents dropping audio with reused message_id

• Repository: openclaw/openclaw
• Author: SymbolStar
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/75078

Description (problem / solution / changelog)

Summary

Fixes #75057

Root Cause

Feishu occasionally reuses the same message_id for different audio attachments sent in quick succession. The inbound dedupe logic (both the in-memory processing claim in monitor.message-handler.ts and the persistent finalize in bot.ts) keyed only on message_id + account, causing the second audio event to be silently dropped as a duplicate.

Fix

Compute a composite dedupe key: message_id:file_key (or message_id:image_key) for media message types (audio, image, file, video, media, sticker). For text messages and true retries (same message_id + same media key), behavior is unchanged.

Affected paths:

• Early processing claim in createFeishuMessageReceiveHandler
• Batch debounce dedup in dedupeFeishuDebounceEntriesByMessageId
• Persistent finalize in handleFeishuMessage
• Suppressed message recording

Test

Added regression test: same message_id with two different file_key values for audio messages → both are dispatched (not deduplicated).

Changed files

• extensions/feishu/src/bot.test.ts (modified, +50/-0)
• extensions/feishu/src/bot.ts (modified, +30/-2)
• extensions/feishu/src/monitor.message-handler.ts (modified, +51/-22)

---

PR #75110: fix(feishu): include audio file_key in dedupe key for distinct uploads (#75057)

• Repository: openclaw/openclaw
• Author: ottodeng
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/75110

Description (problem / solution / changelog)

What

Fixes #75057.

Feishu's inbound dedupe was keyed on (account, message_id) before media content was parsed, so when Feishu reused the same message_id across two distinct voice notes (observed in the wild on 2026.4.27, macOS, with minimax/m2.7), the second voice note was silently dropped before reaching the agent.

Why

clawsweeper's triage on the issue confirmed the root cause: dedupe sees the event before media content is parsed, so it cannot tell two distinct audio payloads apart when the upstream message_id is reused. Telegram does not exhibit this because each Telegram message gets a unique id.

How

Introduce a small helper resolveFeishuMessageDedupeKey(event) in a new extensions/feishu/src/dedupe-key.ts:

• Non-audio events: returns message_id unchanged (zero behavior change).
• Audio events with a parsable file_key in event.message.content: returns ${message_id}:audio:${file_key} so each distinct upload is processed exactly once.
• Audio events without a parsable file_key (malformed JSON, missing/empty file_key): falls back to bare message_id to preserve existing behavior.

All four call sites in extensions/feishu/src/monitor.message-handler.ts were migrated to the helper:

1. dedupeFeishuDebounceEntriesByMessageId (in-flight debounce dedupe)
2. recordSuppressedMessageIds (persisting merged-flush dedupe ids)
3. hasProcessedMessage lookup in the debounce flush path
4. tryBeginFeishuMessageProcessing / releaseFeishuMessageProcessing in the synchronous receive path

extensions/feishu/src/bot.ts was updated to pass the same helper through to the inbound debounce supervisor so receive and dispatch paths agree on the key.

Coverage

Two new test files (232 lines):

• extensions/feishu/src/dedupe-key.test.ts — 6 unit tests covering text/post/audio/audio-without-content/malformed-content/empty-file_key.
• extensions/feishu/src/monitor.message-handler.audio-dedupe.test.ts — 3 integration tests asserting:
  • Same message_id + different file_key → both audio events delivered (the bug).
  • Same message_id + same file_key → second event still dropped (regression guard).
  • Same message_id + text → second event still dropped (no behavior change for non-audio).

Verified locally:

``` node scripts/run-vitest.mjs run extensions/feishu/

→ 63 files, 701 tests, all passing

npx oxlint extensions/feishu/src/{dedupe-key,monitor.message-handler,bot}.ts <new test files>

→ 0 warnings, 0 errors

```

Risk

• Behavior change is scoped to audio events with a parseable file_key. Every other message type takes exactly the same code path as before.
• Persisted dedupe records: the on-disk dedupe store now sees ${message_id}:audio:${file_key} keys for new audio events. Existing entries from before this change remain valid (still bare message_id), so a deployed-during-flight audio with a reused id will be slightly more permissive across the upgrade boundary — acceptable because the buggy behavior was to drop, not double-deliver.
• file_key is a stable Feishu storage identifier, so two voice notes with the same id and same file_key are genuinely the same upload and should still dedupe.

Out of scope

This PR only addresses the audio case from #75057. Image/file/sticker payloads also have file_key-style identifiers but are not part of the reported regression and are left unchanged to keep this fix minimal. If the same message_id-reuse symptom is observed on those types later, the helper is the obvious place to extend.

Changed files

• extensions/feishu/src/bot.ts (modified, +4/-3)
• extensions/feishu/src/dedupe-key.test.ts (added, +106/-0)
• extensions/feishu/src/dedupe-key.ts (added, +40/-0)
• extensions/feishu/src/monitor.message-handler.audio-dedupe.test.ts (added, +126/-0)
• extensions/feishu/src/monitor.message-handler.ts (modified, +24/-20)