Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]:channels.telegram.mediaMaxMb [1 pull requests, 1 comments, 2 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#50036•Fetched 2026-04-08 01:00:01
View on GitHub
Comments
1
Participants
2
Timeline
10
Reactions
0
Author
mikeratterree-botmikeratterree-bot
Participants
Hollychou924Hollychou924mikeratterree-botmikeratterree-bot
Timeline (top)
referenced ×6labeled ×2commented ×1cross-referenced ×1

Version: 2026.3.13 Issue: The inbound attachment size limit (hardcoded at 5MB) cannot be configured via channels.telegram.mediaMaxMb. Setting that key has no effect on inbound downloads. The error thrown is raw and user-facing: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes) Expected behavior: channels.telegram.mediaMaxMb should control the inbound size gate, or a separate channels.telegram.mediaMaxMbInbound key should exist. The default could stay at 5MB but it should be configurable. Note: Telegram's own API supports files up to 50MB — the 5MB ceiling is OpenClaw's alone. Workaround: None currently without building a webhook proxy.

Error Message

Issue: The inbound attachment size limit (hardcoded at 5MB) cannot be configured via channels.telegram.mediaMaxMb. Setting that key has no effect on inbound downloads. The error thrown is raw and user-facing: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes) 3 Observe the error — no graceful handling, raw exception returned to user The channels.telegram.mediaMaxMb config key (which exists in the schema) should control the inbound attachment size limit, allowing operators to raise it above the default 5MB. At minimum, oversized attachments should fail gracefully with a user-friendly message rather than exposing a raw byte-count error. The raw exception is returned directly to the user in chat: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes)

Root Cause

Version: 2026.3.13 Issue: The inbound attachment size limit (hardcoded at 5MB) cannot be configured via channels.telegram.mediaMaxMb. Setting that key has no effect on inbound downloads. The error thrown is raw and user-facing: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes) Expected behavior: channels.telegram.mediaMaxMb should control the inbound size gate, or a separate channels.telegram.mediaMaxMbInbound key should exist. The default could stay at 5MB but it should be configurable. Note: Telegram's own API supports files up to 50MB — the 5MB ceiling is OpenClaw's alone. Workaround: None currently without building a webhook proxy.

Fix Action

Fix / Workaround

Version: 2026.3.13 Issue: The inbound attachment size limit (hardcoded at 5MB) cannot be configured via channels.telegram.mediaMaxMb. Setting that key has no effect on inbound downloads. The error thrown is raw and user-facing: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes) Expected behavior: channels.telegram.mediaMaxMb should control the inbound size gate, or a separate channels.telegram.mediaMaxMbInbound key should exist. The default could stay at 5MB but it should be configurable. Note: Telegram's own API supports files up to 50MB — the 5MB ceiling is OpenClaw's alone. Workaround: None currently without building a webhook proxy.

PR fix notes

PR #50215: fix(gateway): wire agents.defaults.mediaMaxMb to inbound attachment size limit

Description (problem / solution / changelog)

Summary

  • Problem: All three gateway RPC entry points hardcode the inbound attachment size limit to 5 MB, completely ignoring agents.defaults.mediaMaxMb.
  • What changed: Extracted resolveInboundMediaMaxBytes(cfg) helper in chat-attachments.ts. All three call sites now use this helper. Values above the WS transport budget are clamped automatically.
  • What did NOT change: Telegram/channel-specific outbound handling is untouched. The parseMessageWithAttachments signature is unchanged.

Note on default value: The fallback remains 5_000_000 bytes (decimal) to preserve exact backward compatibility. When mediaMaxMb is explicitly configured, it converts as mb * 1024 * 1024 (binary MiB). Values above Math.floor(MAX_PAYLOAD_BYTES * 3 / 4) = 19,660,800 bytes (~18.75 MiB) are clamped so base64-encoded payloads never exceed the 25 MiB WS frame budget.

Change Type

  • Bug fix

Scope

  • Gateway / orchestration

Linked Issue/PR

  • Closes #50036
  • This PR fixes a bug or regression

Root Cause / Regression History

  • Root cause: chat.send, agent.send, and the share node-event handler all hardcoded maxBytes: 5_000_000 instead of reading from config.
  • Missing detection / guardrail: No test verified the config was wired through to the attachment parser.
  • Prior context: The agents.defaults.mediaMaxMb key was added to the schema but the gateway callers were never updated.

Regression Test Plan

  • Coverage level: Unit test
  • Target test: src/gateway/chat-attachments.test.ts - resolveInboundMediaMaxBytes describe block
  • Scenario: returns 5,000,000 default when unset; converts MB to bytes when set; clamps values above WS budget

User-visible / Behavior Changes

  • agents.defaults.mediaMaxMb now controls the inbound attachment size limit for gateway RPCs. Previously ignored and always 5,000,000 bytes.
  • Default is unchanged (5,000,000 bytes) when config is not set.
  • When set, limit is mediaMaxMb * 1024 * 1024 bytes, capped at ~18.75 MiB to stay within the WS frame budget.

Security Impact

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Evidence

Root cause: src/gateway/server-methods/chat.ts, src/gateway/server-methods/agent.ts, src/gateway/server-node-events.ts all hardcoded maxBytes: 5_000_000.

New tests in chat-attachments.test.ts:

  • resolveInboundMediaMaxBytes returns 5,000,000 byte default when config unset
  • resolveInboundMediaMaxBytes converts MB to binary MiB bytes when set
  • resolveInboundMediaMaxBytes clamps values above WS transport budget (~18.75 MiB)
  • parseMessageWithAttachments respects resolved limit (accept and reject paths)

Human Verification

  • All 17 tests in chat-attachments.test.ts pass including 7 new tests
  • Type-check passes for all modified files
  • Edge cases: undefined config, empty agents/defaults objects, explicit MB values, values above WS cap (20 MiB, 100 MiB)

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, default 5,000,000 bytes when mediaMaxMb not set
  • Config/env changes? No
  • Migration needed? No

Failure Recovery

  • How to disable/revert this change quickly: revert src/gateway/chat-attachments.ts to restore hardcoded 5,000,000 limit in all three callers
  • Known bad symptoms: attachments under 5 MB will continue to work unchanged

Risks and Mitigations

  • Risk: Users with mediaMaxMb set above ~18.75 MiB will be silently clamped to the WS budget ceiling.
    • Mitigation: Documented in PR and CHANGELOG. Exceeding the WS frame limit causes a disconnect, which is a worse failure mode.

Changed files

  • CHANGELOG.md (modified, +3/-0)
  • src/gateway/chat-attachments.test.ts (modified, +50/-0)
  • src/gateway/chat-attachments.ts (modified, +24/-0)
  • src/gateway/server-methods/agent.ts (modified, +6/-2)
  • src/gateway/server-methods/chat.ts (modified, +2/-1)
  • src/gateway/server-node-events.runtime.ts (modified, +4/-1)
  • src/gateway/server-node-events.ts (modified, +2/-1)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Version: 2026.3.13 Issue: The inbound attachment size limit (hardcoded at 5MB) cannot be configured via channels.telegram.mediaMaxMb. Setting that key has no effect on inbound downloads. The error thrown is raw and user-facing: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes) Expected behavior: channels.telegram.mediaMaxMb should control the inbound size gate, or a separate channels.telegram.mediaMaxMbInbound key should exist. The default could stay at 5MB but it should be configurable. Note: Telegram's own API supports files up to 50MB — the 5MB ceiling is OpenClaw's alone. Workaround: None currently without building a webhook proxy.

Steps to reproduce

Steps to reproduce:

1 Connect a Telegram account to OpenClaw via openclaw channels 2 Send an image attachment from Telegram that exceeds 5MB to the bot 3 Observe the error — no graceful handling, raw exception returned to user

Expected behavior

The channels.telegram.mediaMaxMb config key (which exists in the schema) should control the inbound attachment size limit, allowing operators to raise it above the default 5MB. At minimum, oversized attachments should fail gracefully with a user-friendly message rather than exposing a raw byte-count error.

Actual behavior

The raw exception is returned directly to the user in chat: Error: attachment image: exceeds size limit (9032347 > 5000000 bytes) The limit is hardcoded in the Telegram channel adapter binary and is not affected by channels.telegram.mediaMaxMb. Setting that key to any value has no effect on inbound downloads. Telegram's own API supports files up to 50MB — the 5MB ceiling is OpenClaw's alone and is not configurable.

OpenClaw version

Version: 2026.3.13

Operating system

macOS 15.4 (Mac Mini M4)

Install method

No response

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw -> anthropic (direct)

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix Plan

To fix the issue, we need to make the inbound attachment size limit configurable via the channels.telegram.mediaMaxMb key. Here are the steps:

  • Update the Telegram channel adapter binary to read the channels.telegram.mediaMaxMb key from the config file.
  • Add a check to ensure the attachment size does not exceed the configured limit.
  • Return a user-friendly error message if the attachment size exceeds the limit.

Example code snippet in JavaScript:

const maxMb = config.channels.telegram.mediaMaxMb || 5; // default to 5MB if not set
const maxBytes = maxMb * 1024 * 1024;

// ...

if (attachment.size > maxBytes) {
  return `Error: attachment exceeds size limit (${attachment.size} > ${maxBytes} bytes)`;
}

// ...

Alternatively, you can add a separate channels.telegram.mediaMaxMbInbound key to control the inbound attachment size limit.

Verification

To verify the fix, follow these steps:

  • Set the channels.telegram.mediaMaxMb key to a value above 5MB (e.g., 10MB) in the config file.
  • Send an image attachment from Telegram that exceeds 5MB but is within the new limit (e.g., 7MB).
  • Verify that the attachment is downloaded successfully.
  • Send an image attachment that exceeds the new limit (e.g., 15MB).
  • Verify that a user-friendly error message is returned.

Extra Tips

  • Make sure to update the documentation to reflect the new configurable attachment size limit.
  • Consider adding a check to ensure the configured limit is within a reasonable range (e.g., 1MB to 50MB) to prevent abuse.

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

The channels.telegram.mediaMaxMb config key (which exists in the schema) should control the inbound attachment size limit, allowing operators to raise it above the default 5MB. At minimum, oversized attachments should fail gracefully with a user-friendly message rather than exposing a raw byte-count error.

#api#ssr#installation#tensor shape#autograd error#optimization#mixed precision#training loop#device allocation

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]:channels.telegram.mediaMaxMb [1 pull requests, 1 comments, 2 participants]