Skip to content

fix(dev-mcp): support bounded 32 MiB image fetches - #7071

Open
jaxxon33 wants to merge 2 commits into
block:mainfrom
jaxxon33:agent/view-image-32mb-source-cap
Open

fix(dev-mcp): support bounded 32 MiB image fetches#7071
jaxxon33 wants to merge 2 commits into
block:mainfrom
jaxxon33:agent/view-image-32mb-source-cap

Conversation

@jaxxon33

Copy link
Copy Markdown

Summary

  • raise the view_image compressed-source cap from 20 MiB to 32 MiB for full-resolution relay photos
  • retain the 10-second connect timeout and add a 30-second whole-request budget plus a 15-second per-read stall deadline
  • preserve same-relay matching, agent-signed media authentication, redirect refusal, pixel limits, decoder allocation limits, and bounded resizing
  • add an authenticated transport regression using a 21 MiB response

Verification

At HEAD 231d33f:

  • cargo test -p buzz-dev-mcp: 101 passed
  • cargo clippy -p buzz-dev-mcp --all-targets -- -D warnings: passed
  • repository-wide cargo fmt and workspace clippy: passed
  • desktop frontend checks: passed

The remaining repository-wide Tauri clippy lane could not run on the ag host because its Linux desktop development packages are absent. A temporary pkg-config executable was supplied, after which the lane reported missing glib-2.0, gobject-2.0, and gio-2.0 metadata. This is disclosed as a host prerequisite gap; no product-code failure was observed.

Fizz and others added 2 commits August 30, 2026 03:42
…eouts

The relay-media path 401'd/oversized on a real ~21.7 MiB full-resolution
phone photo: MAX_SOURCE_BYTES was 20 MiB, and the single 10 s FETCH_TIMEOUT
served as both connect timeout and whole-request budget, which is marginal
for a 20-ish MiB download over a tailnet.

- MAX_SOURCE_BYTES 20 MiB -> 32 MiB. MAX_PIXELS (64 MP) and
  MAX_DECODER_ALLOC (256 MiB) are unchanged, so decode cost stays bounded
  independent of the compressed-source cap.
- Split the single 10 s FETCH_TIMEOUT: CONNECT_TIMEOUT stays 10 s, and each
  streaming read gets its own 15 s READ_STALL_TIMEOUT, so a dead connection
  fails with a named stall error while a slow-but-live 20-ish MiB download
  keeps progressing. The reqwest whole-request `timeout` is deliberately not
  set: it cannot distinguish those two cases. A const assertion binds
  READ_STALL_TIMEOUT to a tokio `timeout` target, so re-adding it as a client
  timeout (which `Into<RequestTimeout>` would silently permit) will not
  typecheck.
- Same-relay origin gate, agent-signed kind-24242 t=get auth, redirect
  refusal, pixel caps, and resize behaviour are untouched.
- Add source_cap_is_32mb_and_documented to keep the tool description's
  advertised cap in sync with the constant.

Signed-off-by: Fizz <fizz@buzz.local>
Add a 30-second whole-request budget alongside the per-read stall timeout so slow-drip peers cannot hold view_image open indefinitely. Exercise the real authenticated transport with a 21 MiB response while keeping the existing origin, redirect, pixel, and allocation guards.

Co-authored-by: Codex <codex@local>
Signed-off-by: Paul <paul@x.net.au>
@jaxxon33
jaxxon33 requested a review from a team as a code owner August 31, 2026 00:29
@github-actions

Copy link
Copy Markdown

🔐 Codex Security Review

Status: review required for the current range.

The current range is eed74bde2f4797714335ac10c56c0b0244c1def4...231d33f8dc1f594de2368db7435c3dff0e0fec37.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 231d33f8dc1f594de2368db7435c3dff0e0fec37 to authorize a new review.
Any previous review applies only to its recorded range.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant