Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Signal attachment fetch hardcoded to 1 MiB HTTP cap; mediaMaxMb cannot override [1 pull requests, 4 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#73564•Fetched 2026-04-29 06:18:09
View on GitHub
Comments
4
Participants
2
Timeline
7
Reactions
0
Author
heyhudsonheyhudson
Participants
clawsweeper[bot]clawsweeper[bot]heyhudsonheyhudson
Timeline (top)
commented ×4cross-referenced ×1mentioned ×1subscribed ×1

MAX_SIGNAL_HTTP_RESPONSE_BYTES is a hardcoded 1 MiB cap in extensions/signal/src/client.ts that the user-facing channels.signal.mediaMaxMb config cannot override. Because signal-cli returns attachments as base64 JSON via POST /api/v1/rpc, even a single ~750 KB photo can exceed the 1 MiB HTTP response cap and be silently dropped — long before mediaMaxMb (default 8 MB; mine is set to 100 MB) is consulted at all.

Error Message

2026-04-28T07:18:16.800-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit 2026-04-28T07:38:01.508-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

Root Cause

MAX_SIGNAL_HTTP_RESPONSE_BYTES is a hardcoded 1 MiB cap in extensions/signal/src/client.ts that the user-facing channels.signal.mediaMaxMb config cannot override. Because signal-cli returns attachments as base64 JSON via POST /api/v1/rpc, even a single ~750 KB photo can exceed the 1 MiB HTTP response cap and be silently dropped — long before mediaMaxMb (default 8 MB; mine is set to 100 MB) is consulted at all.

Fix Action

Fixed

PR fix notes

PR #73572: fix(signal): derive HTTP RPC response cap from mediaMaxMb [AI-assisted]

Description (problem / solution / changelog)

What this fixes

Fixes #73564.

Inbound Signal attachments larger than ~770 KB are silently dropped on every install of OpenClaw. The Signal HTTP RPC client in extensions/signal/src/client.ts rejects any response above a hardcoded 1 MiB cap (MAX_SIGNAL_HTTP_RESPONSE_BYTES). Because signal-cli returns getAttachment payloads as base64 JSON, the response body is ~33% larger than the raw attachment, so the effective fetchable size is ~770 KB regardless of what the user has set channels.signal.mediaMaxMb to. The configured mediaMaxMb (default 8 MB) is only checked after the RPC response is already in hand — but the RPC response is rejected first.

Observed in gateway.err.log:

[signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

…on attachments well below the configured mediaMaxMb.

Fix shape

Mirrors the threading pattern used by #73086 (normalizeSignalSseTimeoutMs):

  1. SignalRpcOptions gains an optional maxResponseBytes.
  2. normalizeSignalHttpResponseMaxBytes returns the value when finite and > 0, otherwise the existing DEFAULT_SIGNAL_HTTP_RESPONSE_MAX_BYTES (1 MiB) so unrelated RPC paths (version, signalCheck, sendReaction, …) keep their existing memory guard.
  3. requestSignalHttpText reads the normalized cap once before opening the response.
  4. monitor.ts:fetchAttachment derives a per-call cap from params.maxBytes (which is built from the effective per-account mediaMaxMb) using a base64 overhead of 4/3 plus a 64 KB JSON envelope headroom, and passes it to signalRpcRequest.

The default constant is renamed DEFAULT_SIGNAL_HTTP_RESPONSE_MAX_BYTES to reflect that it is no longer the only cap in play. No other public types or call sites change.

Affected surface

  • extensions/signal/src/client.ts — type, helper, threading.
  • extensions/signal/src/monitor.ts — derives and passes the per-call cap from fetchAttachment.
  • extensions/signal/src/client.test.ts — four new tests.

Why this is the best possible fix

Codex review on the issue (clawsweeper) prescribed exactly this approach:

Thread a response-size limit through signalRpcRequest/requestSignalHttpText for getAttachment, derive that limit from effective per-account mediaMaxMb with base64 and JSON headroom… and add regression coverage proving allowed multi-megabyte attachments pass while responses above the effective cap still fail.

It also flagged the obvious wrong fix:

Fixing this by removing the HTTP cap entirely would weaken the client memory guard; the safer path is a bounded per-call cap derived from the configured media limit plus base64/JSON headroom…

This PR keeps the bounded per-call cap and leaves the 1 MiB default in place for every other RPC path that does not need to carry attachment data.

Tests

pnpm test extensions/signal — 22 files / 187 tests pass, including:

  • accepts RPC responses larger than the default cap when maxResponseBytes is raised — sends a 1.2 MB payload past the default 1 MiB cap with a 4 MB per-call cap; succeeds.
  • rejects RPC responses that exceed a custom maxResponseBytes cap — 8193 byte response against an 8192 byte cap; rejects with Signal HTTP response exceeded size limit.
  • falls back to the default cap when maxResponseBytes is zero or non-finite — both 0 and Number.POSITIVE_INFINITY fall back to the 1 MiB default and reject 1_048_577 byte responses.
  • The existing rejects oversized RPC responses test still passes unchanged, confirming the default behavior is preserved.

pnpm check:changed — typecheck, lint, runtime sidecar guard, and import-cycle checks all clean.

Verification on a live install

While drafting this PR I ran the equivalent of the SSE half of #73086 against the user's installed 2026.4.26 bundle (/Users/hudson/.local/share/mise/installs/node/22.22.1/lib/node_modules/openclaw/dist/) to verify the threading pattern in production conditions. The HTTP cap fix in this PR is the same shape applied to the source tree.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/signal/src/client.test.ts (modified, +59/-0)
  • extensions/signal/src/client.ts (modified, +13/-2)
  • extensions/signal/src/monitor.ts (modified, +15/-0)

Code Example

2026-04-28T07:18:16.800-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit
2026-04-28T07:38:01.508-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

---

openclaw config set channels.signal.mediaMaxMb 100 --strict-json
   openclaw gateway restart

---

[signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

---

const MAX_SIGNAL_HTTP_RESPONSE_BYTES = 1_048_576;

---

const BASE64_OVERHEAD = 4 / 3;
const HTTP_FRAMING_HEADROOM = 64 * 1024;
const httpResponseCap = Math.ceil(mediaMaxMb * 1024 * 1024 * BASE64_OVERHEAD) + HTTP_FRAMING_HEADROOM;

---

$ rg -n 'MAX_SIGNAL_HTTP_RESPONSE_BYTES' \
    /Users/hudson/.local/share/mise/installs/node/22.22.1/lib/node_modules/openclaw/dist/client-*.js
10:const MAX_SIGNAL_HTTP_RESPONSE_BYTES = 1048576;
83:if (totalBytes > MAX_SIGNAL_HTTP_RESPONSE_BYTES) {

$ jq '.channels.signal.mediaMaxMb' ~/.openclaw/openclaw.json
100

$ tail -n 200 ~/.openclaw/logs/gateway.err.log | rg 'attachment fetch failed'
2026-04-28T07:18:16.800-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit
2026-04-28T07:38:01.508-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

MAX_SIGNAL_HTTP_RESPONSE_BYTES is a hardcoded 1 MiB cap in extensions/signal/src/client.ts that the user-facing channels.signal.mediaMaxMb config cannot override. Because signal-cli returns attachments as base64 JSON via POST /api/v1/rpc, even a single ~750 KB photo can exceed the 1 MiB HTTP response cap and be silently dropped — long before mediaMaxMb (default 8 MB; mine is set to 100 MB) is consulted at all.

Environment

  • OpenClaw version: 2026.4.26 (be8c246)
  • signal-cli version: 0.14.3 (managed by OpenClaw, --http 127.0.0.1:8080 --no-receive-stdout)
  • Node.js: v22.22.1
  • OS: macOS 26.4.1 (Apple Silicon)
  • Install method: mise / npm install -g openclaw
  • Connection method: OpenClaw-managed daemon (autoStart: true, httpHost: 127.0.0.1, httpPort: 8080)

Problem Description

Two attachment fetch caps exist and they are not coupled:

CapWhereDefaultConfigurable
User-facing media capchannels.signal.mediaMaxMb (config)8 MBYes
HTTP response size capMAX_SIGNAL_HTTP_RESPONSE_BYTES (extensions/signal/src/client.ts)1 MiB (1_048_576)No

Because signal-cli serves getAttachment results as base64-encoded JSON over the HTTP RPC, the response body is ~33% larger than the raw attachment. So the effective fetchable attachment size is ~770 KB regardless of what mediaMaxMb is set to. Setting mediaMaxMb=100 does not help — the response is rejected at the HTTP layer first.

In my gateway.err.log:

2026-04-28T07:18:16.800-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit
2026-04-28T07:38:01.508-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

These were ordinary photos under 5 MB, well below my configured mediaMaxMb=100.

Steps to Reproduce

  1. Configure OpenClaw Signal channel with the managed daemon and a generous attachment cap:

    openclaw config set channels.signal.mediaMaxMb 100 --strict-json
openclaw gateway restart

  2. Send any Signal attachment over ~750 KB (e.g. a phone-camera photo) to the bot's account.

  3. Observe in ~/.openclaw/logs/gateway.err.log:

    [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

    The text portion of the message reaches the agent; the attachment is silently dropped.

Model

N/A — channel transport bug, model-independent.

Provider / routing chain

N/A — channel transport bug, model-independent.

Expected behavior

Either:

  • The HTTP response cap should be derived from channels.signal.mediaMaxMb (with a margin for base64 overhead, ~1.4×), so that raising mediaMaxMb actually allows larger attachments through; or
  • Expose the HTTP response cap as a separate config key (e.g. channels.signal.httpResponseMaxBytes) so operators can size it explicitly.

Actual behavior

mediaMaxMb is effectively ignored for inbound Signal attachments larger than ~770 KB. The hardcoded 1 MiB cap wins, the response is rejected, and the attachment is silently dropped before mediaMaxMb enforcement runs.

Suggested Fix

In extensions/signal/src/client.ts, replace the constant:

const MAX_SIGNAL_HTTP_RESPONSE_BYTES = 1_048_576;

with a value derived from the channel config. A reasonable default would be:

const BASE64_OVERHEAD = 4 / 3;
const HTTP_FRAMING_HEADROOM = 64 * 1024;
const httpResponseCap = Math.ceil(mediaMaxMb * 1024 * 1024 * BASE64_OVERHEAD) + HTTP_FRAMING_HEADROOM;

Threaded through the Signal HTTP RPC call sites the same way PR #73086 threaded timeoutMs through runSignalSseLoop → streamSignalEvents → openSignalEventStream.

Related

  • Closely related to #16545 (closed/stale): a separate fetchAttachment 10s-timeout hardcoded value with the same general shape — Signal HTTP defaults that cannot be tuned from config.
  • PR #73086 fixes a sibling case (hardcoded SSE 10s timeout) by introducing normalizeSignalSseTimeoutMs and threading the value from the monitor down to the request. The cap fix would follow the same pattern.

Logs, screenshots, and evidence

$ rg -n 'MAX_SIGNAL_HTTP_RESPONSE_BYTES' \
    /Users/hudson/.local/share/mise/installs/node/22.22.1/lib/node_modules/openclaw/dist/client-*.js
10:const MAX_SIGNAL_HTTP_RESPONSE_BYTES = 1048576;
83:if (totalBytes > MAX_SIGNAL_HTTP_RESPONSE_BYTES) {

$ jq '.channels.signal.mediaMaxMb' ~/.openclaw/openclaw.json
100

$ tail -n 200 ~/.openclaw/logs/gateway.err.log | rg 'attachment fetch failed'
2026-04-28T07:18:16.800-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit
2026-04-28T07:38:01.508-04:00 [signal] attachment fetch failed: Error: Signal HTTP response exceeded size limit

Impact and severity

Affected: any user who receives Signal attachments larger than ~770 KB (i.e., most modern phone photos) Severity: silently drops user content Frequency: every oversized attachment Consequence: agent receives the text portion of a Signal message but never sees the image/audio/video the user attached, with no surfaced error to the user

extent analysis

TL;DR

The issue can be fixed by deriving the HTTP response cap from the channels.signal.mediaMaxMb config, taking into account the base64 overhead.

Guidance

  1. Identify the root cause: The hardcoded MAX_SIGNAL_HTTP_RESPONSE_BYTES constant in extensions/signal/src/client.ts is not overridden by the channels.signal.mediaMaxMb config, causing attachments larger than ~770 KB to be silently dropped.
  2. Calculate the new cap: Use the suggested formula to derive the HTTP response cap from mediaMaxMb, considering the base64 overhead: const httpResponseCap = Math.ceil(mediaMaxMb * 1024 * 1024 * BASE64_OVERHEAD) + HTTP_FRAMING_HEADROOM;.
  3. Update the code: Replace the hardcoded MAX_SIGNAL_HTTP_RESPONSE_BYTES constant with the calculated httpResponseCap value in extensions/signal/src/client.ts.
  4. Verify the fix: Test the updated code by sending attachments larger than ~770 KB and checking if they are received correctly by the agent.

Example

const BASE64_OVERHEAD = 4 / 3;
const HTTP_FRAMING_HEADROOM = 64 * 1024;
const mediaMaxMb = 100; // example value
const httpResponseCap = Math.ceil(mediaMaxMb * 1024 * 1024 * BASE64_OVERHEAD) + HTTP_FRAMING_HEADROOM;

Notes

This fix assumes that the channels.signal.mediaMaxMb config is the correct place to control the attachment size limit. If this is not the case, an alternative approach may be needed.

Recommendation

Apply the workaround by updating the extensions/signal/src/client.ts file to derive the HTTP response cap from the channels.signal.mediaMaxMb config, as this will allow larger attachments to be received correctly.

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

Either:

  • The HTTP response cap should be derived from channels.signal.mediaMaxMb (with a margin for base64 overhead, ~1.4×), so that raising mediaMaxMb actually allows larger attachments through; or
  • Expose the HTTP response cap as a separate config key (e.g. channels.signal.httpResponseMaxBytes) so operators can size it explicitly.
#api#ssr#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

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

Back to top recommendations

TRENDING