Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix No size cap on inbound media downloads (image/audio/video) — potential memory exhaustion [1 pull requests]

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…

The inbound attachment handlers for Discord (and other platforms) download attachment bytes entirely into memory before caching to disk, with no size limit enforced. A large upload — Discord allows up to 500 MB for Nitro users — will be pulled fully into process memory.

Root Cause

The inbound attachment handlers for Discord (and other platforms) download attachment bytes entirely into memory before caching to disk, with no size limit enforced. A large upload — Discord allows up to 500 MB for Nitro users — will be pulled fully into process memory.

PR fix notes

PR #13341: fix(gateway): cap inbound media attachment bytes

Description (problem / solution / changelog)

Fixes #13145.

Root cause: Inbound image/audio attachment caching accepted full byte payloads without a shared size limit. Discord could also call att.read() for known-large image/audio attachments before any cap, which risks loading very large uploads into process memory.

Fix summary:

  • Add a shared inbound media byte cap, defaulting to 128 MiB and overrideable via HERMES_MAX_INBOUND_MEDIA_BYTES.
  • Enforce the cap in cache_image_from_bytes() and cache_audio_from_bytes() before writing to cache.
  • Switch image/audio URL cache downloads to streaming reads that check Content-Length early and abort on chunked overflow.
  • Make Discord check attachment size before authenticated att.read(), and validate returned bytes when size is missing.
  • Add regressions for oversized image/audio cache bytes and a Discord oversized image attachment that must not call att.read().

Tests:

  • uv run --frozen --python 3.11 --extra dev pytest -o addopts= tests/gateway/test_platform_base.py tests/gateway/test_discord_document_handling.py -q -> 90 passed
  • git diff --check -- gateway/platforms/base.py gateway/platforms/discord.py tests/gateway/test_platform_base.py tests/gateway/test_discord_document_handling.py

Changed files

  • gateway/platforms/base.py (modified, +74/-8)
  • gateway/platforms/discord.py (modified, +17/-5)
  • tests/gateway/test_discord_document_handling.py (modified, +20/-0)
  • tests/gateway/test_platform_base.py (modified, +19/-1)
RAW_BUFFERClick to expand / collapse

Bug Report

Summary

The inbound attachment handlers for Discord (and other platforms) download attachment bytes entirely into memory before caching to disk, with no size limit enforced. A large upload — Discord allows up to 500 MB for Nitro users — will be pulled fully into process memory.

Affected code

  • gateway/platforms/base.py — cache_video_from_bytes, cache_image_from_bytes, cache_audio_from_bytes: none enforce a max byte limit before writing to disk.
  • gateway/platforms/discord.py — image, audio, and video attachment handlers all call await att.read() or await resp.read() with no size guard.

Impact

  • A large upload can cause the gateway to consume hundreds of MB of RAM per message.
  • On memory-constrained deployments this can cause OOM kills.
  • No MAX_*_BYTES constant or env-var override exists to cap this.

Suggested fix

Add a configurable size limit (e.g. MAX_ATTACHMENT_BYTES, default ~50–200 MB) to base.py and enforce it in each cache_*_from_bytes helper — raising a ValueError if len(data) > limit. The attachment handlers can then catch this and fall back gracefully (log a warning, skip or fall back to the CDN URL).

Notes

  • Discovered during review of a Discord inbound video support fix.
  • The document handler in discord.py already has a MAX_DOC_BYTES = 32 * 1024 * 1024 guard — the pattern exists, it just needs extending to image, audio, and video.

extent analysis

TL;DR

Implement a configurable size limit for attachments to prevent large uploads from consuming excessive memory.

Guidance

  • Introduce a MAX_ATTACHMENT_BYTES constant or environment variable to enforce a size limit for attachments, with a default value between 50-200 MB.
  • Modify the cache_video_from_bytes, cache_image_from_bytes, and cache_audio_from_bytes functions in base.py to check the size of the attachment data against the configured limit and raise a ValueError if exceeded.
  • Update the attachment handlers in discord.py to catch the ValueError exception and handle it by logging a warning, skipping the attachment, or falling back to the CDN URL.
  • Consider using the existing MAX_DOC_BYTES guard in discord.py as a reference for implementing the size limit for other attachment types.

Example

MAX_ATTACHMENT_BYTES = 50 * 1024 * 1024  # 50 MB default limit

def cache_video_from_bytes(data):
    if len(data) > MAX_ATTACHMENT_BYTES:
        raise ValueError("Attachment exceeds size limit")
    # Cache the attachment to disk

Notes

The suggested fix is based on the existing pattern in discord.py for document handlers, and extending it to other attachment types. The choice of default limit value may need to be adjusted based on specific deployment constraints.

Recommendation

Apply a workaround by introducing a configurable size limit for attachments to prevent large uploads from causing memory issues, as the existing code does not enforce any size limits.

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#installation#tensor shape#autograd error#model save/load

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 No size cap on inbound media downloads (image/audio/video) — potential memory exhaustion [1 pull requests]