openclaw - 💡(How to fix) Fix Discord DMs can fork into duplicate channel sessions during channel-info/network failures [1 comments, 2 participants]

openclaw2026-04-02 17:00:34

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#59817•Fetched 2026-04-08 02:40:12

View on GitHub

Comments

Participants

Timeline

Reactions

Author

DooPeePey

Participants

1168784

DooPeePey

Timeline (top)

commented ×1mentioned ×1subscribed ×1

Discord direct messages can be recorded under multiple session keys for the same conversation when DM channel classification fails during inbound processing.

Expected: a DM with one user should consistently use a single direct session key. Observed: the same DM ended up split across these three keys:

agent:main:discord:direct:113885839649406983 ✅ correct
agent:main:discord:channel:1479021417923350539 ❌ DM channel id treated as guild/channel session
agent:main:discord:channel:113885839649406983 ❌ user id treated as channel id

This fragmented history/context and contributed to replies appearing to disappear.

Error Message

discord channel resolve failed; using config entries. fetch failed | Connect Timeout Error (attempted address: discord.com:443, timeout: 10000ms)

Root Cause

That means if isDirectMessage was never set because channel classification failed, normalization never fixes it.

RAW_BUFFERClick to expand / collapse

Summary

Discord direct messages can be recorded under multiple session keys for the same conversation when DM channel classification fails during inbound processing.

Expected: a DM with one user should consistently use a single direct session key. Observed: the same DM ended up split across these three keys:

agent:main:discord:direct:113885839649406983 ✅ correct
agent:main:discord:channel:1479021417923350539 ❌ DM channel id treated as guild/channel session
agent:main:discord:channel:113885839649406983 ❌ user id treated as channel id

This fragmented history/context and contributed to replies appearing to disappear.

Environment

OpenClaw 2026.4.1
macOS 12.7.6
Discord channel enabled with dmPolicy: pairing
session.dmScope: per-channel-peer

What seems to be happening

Inbound Discord routing appears to depend on resolving channel info and checking:

channelInfo?.type === ChannelType.DM
channelInfo?.type === ChannelType.GroupDM

When that classification fails or times out, the inbound route falls through to channel-mode routing and builds a channel: session key instead of direct:.

Relevant codepaths from installed dist build:

dist/message-handler-6UiYlQq-.js
- const isDirectMessage = channelInfo?.type === ChannelType.DM;
- const isGroupDm = channelInfo?.type === ChannelType.GroupDM;
dist/route-resolution-CRUBXA7Y.js
- kind: params.isDirectMessage ? "direct" : params.isGroupDm ? "group" : "channel"
- id: params.isDirectMessage ? params.directUserId?.trim() || params.conversationId : params.conversationId
dist/session-key-normalization-DZJKr1cT.js
- tries to normalize discord:channel:<id> → discord:direct:<id>, but only when ChatType is already direct

That means if isDirectMessage was never set because channel classification failed, normalization never fixes it.

Evidence from session store

Actual session entries created for the same DM:

Correct direct session

key: agent:main:discord:direct:113885839649406983
origin.chatType: direct
origin.from: discord:113885839649406983
origin.to: channel:1479021417923350539

Wrong channel session using DM channel id

key: agent:main:discord:channel:1479021417923350539
origin.chatType: channel
origin.from: discord:channel:1479021417923350539
origin.to: channel:1479021417923350539
label looked like a guild/channel route even though this was a DM

Wrong channel session using user id

key: agent:main:discord:channel:113885839649406983
origin.chatType: channel
origin.from: discord:channel:113885839649406983
origin.to: channel:113885839649406983

Related logs around the incident

At the same time, there were transient network/connectivity problems:

Discord gateway websocket closed / reconnect scheduled
timeouts connecting to discord.com:443
assistant model timeout/fallback activity

Example log lines:

discord gateway: Gateway websocket closed: 1006
discord channel resolve failed; using config entries. fetch failed | Connect Timeout Error (attempted address: discord.com:443, timeout: 10000ms)
discord: gateway metadata lookup failed transiently; using default gateway url

This makes it look like DM classification is too brittle under partial network failure.

Expected behavior

Even if channel-info lookup is degraded, a Discord DM should still prefer a stable direct-session identity instead of falling back to channel: routing.

Possible fixes

Any of these would likely help:

If guild_id is absent and the sender is a user DM context, prefer direct routing when channel type cannot be resolved.
Make Discord session normalization more aggressive so discord:channel:<userId> and DM-channel cases can be canonicalized to discord:direct:<userId> when enough sender/from metadata exists.
Avoid creating new channel sessions for unresolved DM contexts; defer or reuse existing direct session if present.

Impact

duplicate sessions for one DM
fragmented memory/context
replies can appear missing because the active session is not the one receiving later messages

If useful, I can also provide a sanitized diff of the local sessions.json entries that were created.

extent analysis

TL;DR

Implementing a fallback to prefer direct routing when channel type cannot be resolved, especially in cases of partial network failure, is likely to fix the issue of Discord direct messages being recorded under multiple session keys.

Guidance

Review the dist/message-handler-6UiYlQq-.js and dist/route-resolution-CRUBXA7Y.js codepaths to ensure that when channelInfo?.type cannot be determined, the system defaults to direct routing for user DM contexts.
Enhance the session normalization logic in dist/session-key-normalization-DZJKr1cT.js to more aggressively canonicalize discord:channel:<userId> and DM-channel cases to discord:direct:<userId> based on available sender metadata.
Consider implementing a mechanism to defer or reuse existing direct sessions for unresolved DM contexts instead of creating new channel sessions.

Example

A potential code adjustment in dist/route-resolution-CRUBXA7Y.js could involve adding a conditional check to prefer direct routing when channel type resolution fails:

if (!channelInfo?.type && params.directUserId) {
  kind = "direct";
  id = params.directUserId.trim();
}

Notes

The provided logs indicate transient network/connectivity issues that may have contributed to the channel classification failures. Ensuring robust handling of such failures is crucial. Additionally, the suggested fixes aim to improve the resilience of the DM routing mechanism but may require further testing to ensure they do not introduce unintended behaviors.

Recommendation

Apply a workaround by implementing a fallback to prefer direct routing when channel type cannot be resolved, as this directly addresses the observed issue and can help mitigate the impact of network failures on DM classification.

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?

FAQ

Expected behavior

Even if channel-info lookup is degraded, a Discord DM should still prefer a stable direct-session identity instead of falling back to channel: routing.

#tokenizer error #prompt formatting #chain error #conversation history #tool integration

Still need to ship something?

×6

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

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix Discord DMs can fork into duplicate channel sessions during channel-info/network failures [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Summary

Environment

What seems to be happening

Evidence from session store

Correct direct session

Wrong channel session using DM channel id

Wrong channel session using user id

Related logs around the incident

Expected behavior

Possible fixes

Impact

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix Discord DMs can fork into duplicate channel sessions during channel-info/network failures [1 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Summary

Environment

What seems to be happening

Evidence from session store

Correct direct session

Wrong channel session using DM channel id

Wrong channel session using user id

Related logs around the incident

Expected behavior

Possible fixes

Impact

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING