Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix bug(discord): mixed-attachment messages can be misclassified as plain text [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
NousResearch/hermes-agent#11771•Fetched 2026-04-18 05:58:53
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
NewTurn2017NewTurn2017
Participants
NewTurn2017NewTurn2017
Timeline (top)
cross-referenced ×1

Root Cause

That matters because downstream handling treats photo follow-ups specially, but only when message_type == PHOTO.

Fix Action

Fixed

PR fix notes

PR #11871: fix(discord): ignore unsupported attachments when typing messages

Description (problem / solution / changelog)

Summary

  • keep scanning Discord attachments until the first supported media type is found instead of breaking on the first unsupported content_type
  • preserve existing document semantics for oversized or failed downloads while fixing mixed unsupported-plus-image cases
  • add a regression test covering an unsupported attachment followed by an image

Testing

  • python3 -m pytest -o addopts='' tests/gateway/test_discord_document_handling.py
  • python3 -m pytest -o addopts='' tests/gateway/test_discord_attachment_download.py

Closes #11771

Changed files

  • gateway/platforms/discord.py (modified, +24/-16)
  • tests/gateway/test_discord_document_handling.py (modified, +25/-0)
RAW_BUFFERClick to expand / collapse

Bug Description

Discord _handle_message() stops scanning attachments after the first attachment that has a content_type. If that first attachment is unsupported/non-media but a later attachment is an image/audio/document, the event can be emitted as MessageType.TEXT even though media_types contains real media.

Affected Files / Lines

  • gateway/platforms/discord.py:2315-2332
  • gateway/platforms/discord.py:2371-2463
  • gateway/platforms/base.py:1544-1550

Why this is a bug

The first loop decides msg_type and breaks early, but the second loop still processes all attachments. That allows inconsistent events such as:

  • message_type == MessageType.TEXT
  • media_types == ['image/png']

That matters because downstream handling treats photo follow-ups specially, but only when message_type == PHOTO.

Minimal Reproduction

A Discord message with:

  1. attachment 1 = application/octet-stream / blob.bin
  2. attachment 2 = image/png / photo.png

Observed in repo environment after calling _handle_message():

  • event.message_type == MessageType.TEXT
  • event.media_types == ['image/png']

Expected Behavior

Message type should be derived from all attachments (or from the processed media_types result), so a message carrying an image is classified consistently.

Actual Behavior

The first unsupported attachment locks the event into TEXT, even when later attachments are valid media.

Suggested Investigation Direction

Determine msg_type after processing all attachments, or continue scanning until the highest-priority supported attachment type is found instead of breaking on the first content_type.

extent analysis

TL;DR

The issue can be fixed by determining the msg_type after processing all attachments, rather than breaking early after the first attachment with a content_type.

Guidance

  • Review the loops in discord.py (lines 2315-2332 and 2371-2463) to understand how msg_type is currently being determined and how it can be modified to consider all attachments.
  • Consider adding a conditional statement to continue scanning attachments until a supported media type is found, rather than breaking on the first content_type.
  • Verify the fix by testing with a message containing multiple attachments, including at least one unsupported and one supported media type.
  • Check the event.message_type and event.media_types to ensure they are correctly set after the fix.

Example

# Pseudocode example, actual implementation may vary
for attachment in attachments:
    if attachment.content_type in supported_media_types:
        msg_type = MessageType.PHOTO  # or other supported type
        break
else:
    msg_type = MessageType.TEXT

Notes

The suggested fix assumes that the supported_media_types list is already defined and accessible. The actual implementation may require additional modifications to the existing code.

Recommendation

Apply a workaround by modifying the _handle_message() function to continue scanning attachments until a supported media type is found, rather than breaking early. This will ensure that the msg_type is correctly determined based on all attachments, rather than just the first one.

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#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix bug(discord): mixed-attachment messages can be misclassified as plain text [1 pull requests, 1 participants]