Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Discord forward message content not parsed — only metadata visible to agent [1 pull requests, 1 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#61664•Fetched 2026-04-08 02:56:14
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
leon80900leon80900
Participants
leon80900leon80900
Timeline (top)
closed ×1cross-referenced ×1

Root Cause

Discord's message_reference structure contains forwarded content in referenced_message.content, but OpenClaw's Discord adapter only parses the top-level metadata, not the nested reference.

Fix Action

Workaround

Copy-paste message text instead of using Discord's forward feature.

PR fix notes

PR #61670: fix(discord): recover forwarded referenced message content

Description (problem / solution / changelog)

Summary

  • Problem: Discord forwarded messages could reach the agent with only Conversation info metadata when Discord populated referenced_message but did not include message_snapshots.
  • Why it matters: forwarded handoff content becomes invisible to the agent, which breaks Discord-based multi-agent coordination and forces users to copy-paste instead of using Forward.
  • What changed: the Discord inbound message path now falls back to messageReference.type === Forward + referencedMessage when snapshots are absent, for both forwarded text and forwarded attachments.
  • What did NOT change (scope boundary): this PR does not change ordinary reply handling, thread-starter resolution beyond existing behavior, or non-Discord channels.

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 #61664
  • Related #60139
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: extensions/discord/src/monitor/message-utils.ts only treated message_snapshots as forwarded-message content. When Discord delivered a forward via message_reference.type = Forward plus referenced_message, OpenClaw kept the reply metadata but dropped the forwarded body and attachments from the main inbound content path.
  • Missing detection / guardrail: there was no regression test for forwarded messages that carry content only in referencedMessage.
  • Prior context (git blame, prior PR, issue, or refactor if known): #60139 fixed a related Discord forwarded-message gap for thread starter resolution, but explicitly stayed out of message-utils.ts and regular inbound processing.
  • Why this regressed now: this appears to be an unsupported Discord forward representation rather than a recent regression introduced by this PR.
  • If unknown, what was ruled out: the issue is not limited to message_snapshots; local code inspection confirmed the regular inbound path already handled snapshots but had no referencedMessage fallback.

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-utils.test.ts
  • Scenario the test should lock in: forwarded Discord messages with messageReference.type === Forward and no snapshots still surface referenced text and referenced attachments to the agent, while ordinary replies do not get treated as forwarded context.
  • Why this is the smallest reliable guardrail: the bug is isolated to the Discord message text/media normalization helpers, so unit tests on that seam directly cover the dropped-content path without requiring a live Discord runtime.
  • Existing test that already covers this (if any): existing tests already covered snapshot-based forwarded content only.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

Discord forwarded messages now preserve forwarded body text and forwarded attachments in the inbound agent context even when Discord sends them via referenced_message instead of message_snapshots.

Diagram (if applicable)

Before:
[Discord forward] -> referenced_message only -> metadata reaches agent -> forwarded content missing

After:
[Discord forward] -> referenced_message only -> fallback extracts body/media -> agent sees forwarded content

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: Ubuntu 24.04.3
  • Runtime/container: Node 22 / pnpm workspace
  • Model/provider: N/A
  • Integration/channel (if any): Discord
  • Relevant config (redacted): N/A

Steps

  1. Create a Discord message object whose forward content is available only via messageReference.type === Forward and referencedMessage, with no message_snapshots.
  2. Run the Discord inbound message normalization helpers.
  3. Confirm the agent-facing text/media include the forwarded content, and that ordinary replies still do not get treated as forwarded context.

Expected

  • Forwarded referenced text is included in the inbound content.
  • Forwarded referenced attachments are preserved in forwarded media resolution.
  • Non-forward replies remain unchanged.

Actual

  • Matches expected with the patch.

Evidence

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

Human Verification (required)

  • Verified scenarios: ran pnpm test -- extensions/discord/src/monitor/message-utils.test.ts; confirmed new tests pass for referenced forwarded text, referenced forwarded attachments, and ordinary reply non-regression. Ran pnpm build successfully in the main workspace before preparing the clean PR branch.
  • Edge cases checked: snapshot-based forwarded messages still work; ordinary replies with messageReference.type === Default are not treated as forwarded context; forwarded attachments still resolve when snapshots are absent.
  • What you did not verify: end-to-end with a live Discord forwarded message event against a running OpenClaw instance.

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/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: Discord could send message references for ordinary replies and forwarded messages through the same fields in some future shape change.
    • Mitigation: the fallback is gated specifically on messageReference.type === Forward, and there is a regression test asserting ordinary replies stay unchanged.
  • Risk: snapshot-based forwarded handling could regress while adding the fallback path.
    • Mitigation: existing snapshot tests still pass, and the fallback only runs when snapshots are absent.

AI-Assisted

  • AI-assisted (Codex)
  • Fully tested locally for the touched surface
  • Understand what the code does

Changed files

  • extensions/discord/src/monitor/message-utils.test.ts (modified, +86/-1)
  • extensions/discord/src/monitor/message-utils.ts (modified, +79/-28)

Code Example

{
     "message_id": "1490525349572776086",
     "sender_id": "1282138889024307260",
     "sender": "chenhl",
     "timestamp": "Mon 2026-04-06 09:35 GMT+8"
   }

---

{
  "id": "1490525349572776086",
  "author": { "id": "1282138889024307260", ... },
  "timestamp": "2026-04-06T01:35:37.973Z",
  "message_reference": {
    "message_id": "original_msg_id",
    "channel_id": "original_channel_id"
  },
  "referenced_message": {
    "content": "ACTUAL FORWARDED CONTENT HERE",
    "author": { ... },
    ...
  }
}
RAW_BUFFERClick to expand / collapse

name: Bug Report about: Discord forward message content not parsed title: "Discord forward message content not parsed — only metadata visible to agent" labels: bug, discord, message-parsing assignees: ""

Bug Description

When user forwards a message from another channel/user in Discord, OpenClaw only receives the metadata (message_id, sender_id, timestamp) but not the actual forwarded content.

Expected Behavior

Forwarded message content should be visible to the agent, same as copy-pasted text.

Actual Behavior

Only Conversation info metadata is received, content is empty.

Steps to Reproduce

  1. User forwards a message from CEO channel to Main DM in Discord
  2. Main agent receives only: 
    {
  "message_id": "1490525349572776086",
  "sender_id": "1282138889024307260",
  "sender": "chenhl",
  "timestamp": "Mon 2026-04-06 09:35 GMT+8"
}
  3. No forwarded text content available in content field

Environment

  • OpenClaw Version: 2026.4.2
  • Channel: Discord
  • Agent: main (bailian/kimi-k2.5)

Root Cause Analysis

Discord's message_reference structure contains forwarded content in referenced_message.content, but OpenClaw's Discord adapter only parses the top-level metadata, not the nested reference.

Discord API Structure (simplified)

{
  "id": "1490525349572776086",
  "author": { "id": "1282138889024307260", ... },
  "timestamp": "2026-04-06T01:35:37.973Z",
  "message_reference": {
    "message_id": "original_msg_id",
    "channel_id": "original_channel_id"
  },
  "referenced_message": {
    "content": "ACTUAL FORWARDED CONTENT HERE",
    "author": { ... },
    ...
  }
}

Workaround

Copy-paste message text instead of using Discord's forward feature.

Impact

  • Affects multi-agent coordination workflow
  • User must manually copy content when forwarding between agent channels
  • Breaks seamless handoff between CEO/CTO/Security and Main

Suggested Fix

Update Discord message adapter to:

  1. Check for message_reference presence
  2. If present, extract referenced_message.content
  3. Include in agent context as forwarded_content or merge into content

Priority

Medium — workaround exists but impacts UX

Related

  • Multi-agent dispatch policy
  • Cross-session messaging

extent analysis

TL;DR

Update the Discord message adapter to parse the referenced_message.content field when a message_reference is present.

Guidance

  • Review the Discord API structure to understand the message_reference and referenced_message fields.
  • Modify the Discord adapter to check for the presence of message_reference and extract the referenced_message.content if available.
  • Consider adding a new field, such as forwarded_content, to the agent context to store the extracted content.
  • Test the updated adapter with forwarded messages to verify that the content is correctly parsed and included in the agent context.

Example

// Example of updated Discord message adapter output
{
  "message_id": "1490525349572776086",
  "sender_id": "1282138889024307260",
  "sender": "chenhl",
  "timestamp": "Mon 2026-04-06 09:35 GMT+8",
  "forwarded_content": "ACTUAL FORWARDED CONTENT HERE"
}

Notes

The suggested fix assumes that the Discord API consistently includes the referenced_message field when a message is forwarded. Additional error handling may be necessary to handle cases where this field is missing or empty.

Recommendation

Apply the suggested fix to update the Discord message adapter, as it provides a more seamless user experience and improves the functionality of the multi-agent coordination workflow.

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…
#api#integration issue#index setup#retrieval issue#search optimization

Still need to ship something?

×6

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

Back to top recommendations

TRENDING