openclaw - ✅(Solved) Fix Discord DM: single message processed twice (normal + spurious queued replay) [1 pull requests, 5 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73441Fetched 2026-04-29 06:19:53
View on GitHub
Comments
5
Participants
3
Timeline
8
Reactions
0
Timeline (top)
commented ×5closed ×1cross-referenced ×1renamed ×1

Fix Action

Fixed

PR fix notes

PR #73608: fix(discord): deduplicate accounts sharing the same bot token

Description (problem / solution / changelog)

Bug

Fixes #73441

Discord DM messages are processed twice when two accounts resolve to the same bot token. The user sends one message but receives two responses.

Root Cause

resolveDiscordToken() has a fallback chain: account-level token → top-level channels.discord.tokenDISCORD_BOT_TOKEN env var (for the default account only).

The OpenClaw service manager injects DISCORD_BOT_TOKEN as a managed env var. If a user has a named account (e.g. work) with an explicit token and a default account entry with no configured token, the default account silently picks up the same bot token via the env var fallback.

Both accounts pass the startup filter (enabled && hasToken), so two independent monitors connect to Discord with the same bot credentials. Each monitor has its own replay guard, so both claim the same inbound message:

  1. Monitor A processes the message normally → agent replies
  2. Monitor B also receives it, but the agent is now busy → message gets enqueued as [Queued messages while agent was busy]
  3. Agent finishes → followup queue drains → agent replies again

Fix

Add deduplicateDiscordAccountsByToken() that groups resolved accounts by token value and keeps only one per unique token. When duplicates exist, the account with source: "config" (explicit config) is preferred over source: "env" (env var fallback). A warning is logged when deduplication occurs.

Applied in two places:

  • listEnabledDiscordAccounts() — affects monitor startup
  • resolveDiscordStartupDelayMs() — affects staggered startup timing

Workaround

Users hitting this today can remove the redundant account entry:

openclaw config unset channels.discord.accounts.default
openclaw gateway restart

Tests

4 new tests covering:

  • Config-sourced account kept over env-sourced when tokens match
  • Both accounts kept when tokens differ
  • First account kept when same token and same source
  • Empty-token accounts not deduplicated

Changed files

  • extensions/discord/src/accounts.test.ts (modified, +56/-1)
  • extensions/discord/src/accounts.ts (modified, +39/-1)
  • extensions/discord/src/channel.ts (modified, +10/-7)
RAW_BUFFERClick to expand / collapse

Bug

In Discord DM conversations, a single user message gets processed twice:

  1. First as a normal inbound message → agent replies
  2. Then again as a [Queued messages while agent was busy] replay → agent replies a second time

The user sends one message but receives two responses.

Reproduction

  1. Send a single message (e.g. "hi") to the agent in a Discord DM
  2. The agent responds normally
  3. The same message immediately appears again as a queued message
  4. The agent responds a second time to the duplicate

Screenshot

From the web UI showing the duplicate processing:

  • User sends: hi
  • Agent replies: hi Luna~ 🌸 在呢,有什么事?
  • Same hi replayed as: [Queued messages while agent was busy] Queued #1 (from Luna) hi
  • Agent replies again: 嘿 已经回了你啦~

Scope

  • Affected: Discord DM only
  • Not affected: Discord server channels (group chats work correctly)
  • Persists after upgrade to latest version (2026.4.24+)

Expected behavior

A single message should be processed exactly once. The queued message mechanism should not replay messages that have already been handled.

extent analysis

TL;DR

The issue can be mitigated by modifying the message processing logic to ignore queued messages that have already been handled.

Guidance

  • Review the message processing code to identify why the queued message mechanism is replaying already handled messages.
  • Verify that the message ID or unique identifier is being correctly stored and checked to prevent duplicate processing.
  • Investigate the agent's busy state handling to ensure it's not causing the message to be queued unnecessarily.
  • Consider adding a flag or marker to indicate when a message has been processed to prevent replaying.

Example

No code snippet is provided as the issue lacks specific implementation details.

Notes

The issue seems to be specific to Discord DM conversations and doesn't occur in server channels. The problem persists even after upgrading to the latest version.

Recommendation

Apply a workaround by modifying the message processing logic to ignore queued messages that have already been handled, as the root cause is unclear and an upgrade to a fixed version is not implied.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

A single message should be processed exactly once. The queued message mechanism should not replay messages that have already been handled.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING