PR #63104: fix(discord): dedupe inbound deliveries across handler instances

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

Description (problem / solution / changelog)

Closes #63027

Summary

• Problem: Discord could send duplicate replies for a single inbound DM when the same inbound delivery reached more than one createDiscordMessageHandler(...) instance.
• Why it matters: One user message could trigger two reply paths, including an extra queued follow-up reply, which matches the behavior reported in #63027 and doubles token spend.
• What changed: Moved Discord inbound dedupe from handler-instance scope to a process-global cache, keyed by accountId + messageId, and added a regression test for duplicate delivery across distinct handler instances.
• What did NOT change (scope boundary): This PR does not change queue semantics, provider behavior, or the upstream listener lifecycle that may cause duplicate deliveries to appear in the first place.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #63027
• Related #N/A
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: extensions/discord/src/monitor/message-handler.ts created its inbound dedupe cache inside createDiscordMessageHandler(), so dedupe only worked within a single handler instance.
• Missing detection / guardrail: There was no regression test covering the same Discord message.id being delivered to two distinct handler instances.
• Contributing context (if known): Duplicate deliveries can happen when monitor/listener lifecycle overlap or reconnect paths surface the same inbound event more than once. The exact upstream trigger from the field report is still unknown, but this layer should have rejected the duplicate anyway.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/discord/src/monitor/message-handler.queue.test.ts
• Scenario the test should lock in: Two distinct Discord handlers receive the same inbound Discord message with the same message.id, and only one processing path runs.
• Why this is the smallest reliable guardrail: A single-handler test cannot catch this bug because the failure only appears when dedupe must span handler instances.
• Existing test that already covers this (if any): None.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Discord inbound messages are no longer replied to twice when the same inbound delivery is observed by more than one handler instance in the same process.
• In queue mode: collect, users should no longer see the extra queued follow-up reply that was caused by the duplicate second processing path.

Diagram (if applicable)

Before:
[one Discord inbound message]
  -> [handler A sees message.id = X] -> [reply path runs]
  -> [handler B sees message.id = X] -> [duplicate reply / queued follow-up]

After:
[one Discord inbound message]
  -> [handler A or B claims message.id = X in global dedupe cache]
  -> [reply path runs once]
  -> [duplicate delivery dropped]

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:

Repro + Verification

Environment

• OS: local reproduction on macOS; original issue report says Linux
• Runtime/container: Node v25.3.0, pnpm 10.32.1
• Model/provider: Not provider-specific; reproduced with mocked Discord inbound processing
• Integration/channel (if any): Discord DM
• Relevant config (redacted): Discord auto-reply enabled; queue mode collect

Steps

1. Create two distinct createDiscordMessageHandler(...) instances.
2. Deliver the same inbound Discord event with the same message.id to both handlers.
3. Observe whether the message is processed once or twice.

Expected

• One inbound Discord message.id should be processed once per process.

Actual

• Before this fix, the same inbound Discord message.id was processed twice when it reached two handler instances, which could surface as a duplicate queued follow-up reply.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Before fix:

• New regression scenario failed locally because one inbound Discord message id triggered processDiscordMessageMock 2 times instead of the expected 1 time.

After fix:

• pnpm test extensions/discord/src/monitor/message-handler.queue.test.ts

  • Test Files: 1 passed (1)
  • Tests: 16 passed (16)

• pnpm test extensions/discord/src/monitor/message-handler.process.test.ts

  • Test Files: 1 passed (1)
  • Tests: 28 passed (28)

• pnpm test extensions/discord/src/monitor/monitor.test.ts

  • Test Files: 1 passed (1)
  • Tests: 22 passed (22)

• pnpm test:extension discord

  • Test Files: 112 passed (112)
  • Tests: 929 passed (929)

Human Verification (required)

• Verified scenarios: Added and ran a regression test for duplicate delivery across distinct handler instances; reran the touched Discord handler/monitor test files; ran the recommended extension lane pnpm test:extension discord.
• Edge cases checked: Duplicate delivery within one handler instance; duplicate delivery across distinct handler instances; global dedupe state reset between tests so test isolation stays intact.
• What you did not verify: Live Discord DM behavior against a real account; Linux-specific runtime behavior; the exact upstream source of duplicate deliveries in the field; full-repo pnpm build && pnpm check && pnpm test.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: A process-global dedupe cache could suppress intentional reprocessing if the exact same Discord message.id were somehow replayed inside the TTL window.

  • Mitigation: Discord message ids are globally unique snowflakes, and the correct behavior for a single inbound message id is exactly-once processing per process. The cache is also bounded by TTL and accountId.

• Risk: A shared dedupe cache can leak across tests and create false positives.

  • Mitigation: Added __resetDiscordInboundDedupeForTest() and wired it into test helpers so each test starts from a clean dedupe state.

AI Assistance

Made with Codex

Changed files

• extensions/discord/src/monitor.tool-result.test-helpers.ts (modified, +5/-1)
• extensions/discord/src/monitor/inbound-worker.ts (modified, +7/-2)
• extensions/discord/src/monitor/message-handler.module-test-helpers.ts (modified, +11/-3)
• extensions/discord/src/monitor/message-handler.queue.test.ts (modified, +35/-0)
• extensions/discord/src/monitor/message-handler.ts (modified, +33/-11)