fix(minimax-vlm): bound VLM API response reads by cxbAsDev · Pull Request #96264 · openclaw/openclaw

cxbAsDev · 2026-06-24T02:58:51Z

Summary

Replace raw res.json() with readResponseWithLimit in the MiniMax VLM image-understanding provider to prevent unbounded buffering of API responses.

Real behavior proof (required for external PRs)

Behavior addressed: Unbounded res.json() replaced with readResponseWithLimit (16 MB cap).

Real environment tested: Linux, Node 24, OpenClaw main @ 0671c08

Exact steps or command run after fix:

node --import tsx proof-minimax-vlm.mts

Evidence after fix:

cap: 16777216 bytes (16 MiB)
chunks pulled: 17
error: MiniMax VLM response exceeds 16777216 bytes
PASS: reader stopped at cap, stream cancelled before full buffering

The harness creates a streaming 64 MB JSON body with 1 MB chunks. The reader pulls only 17 chunks (stopping at the 16 MB cap), cancels the stream, and throws the overflow error. Before the fix, res.json() would have buffered the entire 64 MB before parsing.

Observed result after fix: readResponseWithLimit caps the MiniMax VLM API response at 16 MB. Streaming bodies are cancelled at the cap instead of being fully buffered.

What was not tested: A live MiniMax VLM API call against api.minimax.io was not tested.

Risk

Low. 16 MB cap matches the convention in provider-http-errors.ts. Original error path (catch → null → "response was not JSON") is preserved for overflow errors too.

clawsweeper · 2026-06-24T04:48:01Z

Codex review: needs maintainer review before merge. Reviewed July 1, 2026, 12:50 AM ET / 04:50 UTC.

Summary
The PR routes MiniMax VLM successful JSON parsing through readProviderJsonResponse and updates MiniMax/media-understanding tests to provide response bodies compatible with the bounded reader.

PR surface: Source +8, Tests +100. Total +108 across 4 files.

Reproducibility: yes. for source-level reproduction: current main still calls raw res.json() on successful MiniMax VLM responses, and the PR proof shows the bounded reader stopping at the 16 MiB cap. I did not run a live MiniMax API or memory-pressure repro in this read-only review.

Review metrics: 1 noteworthy metric.

Provider Success-Response Cap: 1 added: MiniMax VLM successful JSON reads now capped at 16 MiB. This is the user-visible behavior change maintainers need to accept before merge because oversized successful provider responses now fail closed.

Stored data model
Persistent data-model change detected: serialized state: src/agents/tools/image-tool.test.ts, serialized state: src/media-understanding/image.test.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: canonical
Canonical: #96264
Summary: This PR is the focused canonical MiniMax VLM success-response bound; one closed sibling duplicated the same head, one merged sibling fixed MiniMax video reads, and one broader open guard partially overlaps but is not a direct replacement yet.

Members:

superseded: fix(agents): bound MiniMax VLM and native PDF provider JSON response reads to prevent OOM #98191 - Closed unmerged by the same author with the same head SHA and a comment saying it was superseded by a fresh PR.
same_root_cause: fix(minimax): bound video control response reads #96889 - Merged PR fixed the same unbounded successful JSON response-read pattern in MiniMax video control paths, not the VLM image path.
partial_overlap: fix(boundary-safety): guard response reads and UTF-16 truncation #97774 - Open broader boundary-safety guard includes overlapping MiniMax VLM bounded-read work but also changes tooling, baselines, and unrelated boundary surfaces.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Maintainers should accept the 16 MiB cap, tune it, or choose the broader overlapping guard PR as the canonical path before merge.

Risk before merge

[P1] Successful MiniMax VLM JSON responses larger than 16 MiB will now fail closed instead of being fully buffered and parsed, so maintainers should explicitly accept that provider compatibility tradeoff or choose a provider-specific limit.
[P1] No live MiniMax API call was shown; the proof covers the local fetch/Response boundary and stream cancellation, not real service payload sizes.
[P1] The broader open boundary-safety PR also overlaps the MiniMax VLM success-read path, so maintainers should pick the intended canonical landing path before merging duplicate behavior.

Maintainer options:

Accept The Shared MiniMax VLM Cap (recommended)
Maintainers can merge this focused patch after explicitly accepting that oversized successful MiniMax VLM JSON responses fail closed at 16 MiB.
Tune The Provider Limit First
If legitimate MiniMax VLM responses may exceed 16 MiB, set an explicit provider-approved cap and keep the overflow coverage aligned with that choice.
Use The Broader Guard Instead
If maintainers prefer the broader boundary-safety PR to own this response-read invariant, pause or close this focused PR only after the broader path is confirmed viable.

Next step before merge

[P2] Human maintainer judgment remains for the 16 MiB provider compatibility tradeoff and canonical branch choice; there is no narrow automated code repair blocker.

Security
Cleared: No concrete security or supply-chain concern found; the diff narrows provider-controlled response buffering and changes no dependencies, workflows, permissions, package metadata, or secret handling.

Review details

Best possible solution:

Land the focused shared-helper MiniMax VLM bounded read after maintainer cap acceptance, or tune the cap explicitly before merge; keep broader guard work separate unless maintainers choose that as the canonical path.

Do we have a high-confidence way to reproduce the issue?

Yes for source-level reproduction: current main still calls raw res.json() on successful MiniMax VLM responses, and the PR proof shows the bounded reader stopping at the 16 MiB cap. I did not run a live MiniMax API or memory-pressure repro in this read-only review.

Is this the best way to solve the issue?

Yes for the code shape: reusing readProviderJsonResponse at the MiniMax VLM parse point is the narrow shared-owner fix. The remaining question is whether maintainers accept the shared 16 MiB cap for this provider or want a provider-specific limit.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against d68ba5edc598.

Label changes

Label justifications:

P2: This is a focused MiniMax VLM provider hardening fix with limited blast radius and normal maintainer priority.
merge-risk: 🚨 compatibility: The PR intentionally changes oversized successful MiniMax VLM JSON responses from unbounded parsing to a 16 MiB fail-closed error.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes after-fix terminal output from a Node 24 oversized streaming-response harness showing the 16 MiB cap and early cancellation; no live MiniMax call was shown.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix terminal output from a Node 24 oversized streaming-response harness showing the 16 MiB cap and early cancellation; no live MiniMax call was shown.

Evidence reviewed

PR surface:

Source +8, Tests +100. Total +108 across 4 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	9	1	+8
Tests	3	109	9	+100
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	4	118	10	+108

What I checked:

Repository policy applied: Root AGENTS.md and scoped src/agents/AGENTS.md and src/agents/tools/AGENTS.md were read fully; the fail-closed provider behavior was treated as compatibility-sensitive per repository review policy. (AGENTS.md:15, d68ba5edc598)
Current main still has the unbounded MiniMax VLM read: minimaxUnderstandImage on current main still calls res.json().catch(() => null) on successful responses, so the central behavior is not already implemented on main. (src/agents/minimax-vlm.ts:145, d68ba5edc598)
PR uses the shared bounded JSON reader: The live PR diff imports readProviderJsonResponse and replaces the raw success-response read with readProviderJsonResponse<Record<string, unknown>>(res, "MiniMax VLM"), preserving Trace-Id context on errors. (src/agents/minimax-vlm.ts:143, 1864802a0445)
Shared helper enforces the default JSON byte cap: readProviderJsonResponse reads through readResponseWithLimit and defaults provider JSON responses to the 16 MiB cap. (src/agents/provider-http-errors.ts:315, d68ba5edc598)
Bounded reader cancels streams on overflow: readResponseWithLimit stops when the next chunk exceeds the max byte budget, cancels the reader, and throws the configured overflow error. (packages/media-core/src/read-response-with-limit.ts:96, d68ba5edc598)
MiniMax VLM caller path checked: describeImagesWithMinimax is the image-understanding caller that forwards MiniMax VLM image requests into minimaxUnderstandImage. (src/media-understanding/image.ts:335, d68ba5edc598)

Likely related people:

steipete: Commit 36a02b3e... added MiniMax VLM routing, src/agents/minimax-vlm.ts, and the original successful-response parsing path now being hardened. (role: introduced behavior; confidence: high; commits: 36a02b3e6755; files: src/agents/minimax-vlm.ts, src/agents/tools/image-tool.test.ts)
Alix-007: Commit 2592f8a... and merged fix(agents): bound provider JSON response reads #95218 introduced readProviderJsonResponse and its overflow coverage, which this PR reuses. (role: shared helper contributor; confidence: high; commits: 2592f8a51a4e; files: src/agents/provider-http-errors.ts, src/agents/provider-http-errors.test.ts)
vincentkoc: Recent commits in the same MiniMax/provider response area bounded MiniMax VLM error bodies, clamped request timeouts, and shared the bounded error-body reader. (role: recent provider hardening contributor; confidence: high; commits: 4f26cc9090d0, 4b6182ee2a25, b31bf811cbfa; files: src/agents/minimax-vlm.ts, src/infra/http-error-body.ts)
joshavant: Commit 0a144449... broadened successful provider response-read bounding across sibling provider surfaces and touched the same shared helper family. (role: recent shared response-read contributor; confidence: medium; commits: 0a14444924e3; files: src/agents/provider-http-errors.ts, src/plugin-sdk/provider-http.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

cxbAsDev · 2026-06-24T06:07:40Z

@clawsweeper re-review

clawsweeper · 2026-06-24T06:07:42Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

cxbAsDev · 2026-06-25T08:28:04Z

@clawsweeper re-review

clawsweeper · 2026-06-25T08:28:07Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Replace unbounded res.json() with readProviderJsonResponse (16 MiB cap) in minimaxUnderstandImage success path. Preserve MiniMax Trace-Id header in malformed/overflow error messages. Includes: - Mocked oversized-stream test with Trace-Id verification - Real TCP HTTP server behavior proof test Co-Authored-By: Claude <[email protected]>

cxbAsDev · 2026-07-01T14:28:08Z

@clawsweeper re-review

Rebased onto latest main. Now 2 files only (removed unrelated image-tool/image test changes). Uses readProviderJsonResponse with Trace-Id preservation. 14 tests pass including real HTTP server proof.

clawsweeper · 2026-07-01T14:28:11Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

openclaw-barnacle Bot added agents Agent runtime and tooling size: XS labels Jun 24, 2026

This was referenced Jun 28, 2026

fix(minimax): bound video control response reads #96889

Merged

fix(agents): bound MiniMax VLM and native PDF provider JSON response reads to prevent OOM #98191

Closed

cxbAsDev force-pushed the fix/bound-minimax-vlm-response branch from 3cfe393 to 1864802 Compare July 1, 2026 04:35

openclaw-barnacle Bot removed the size: XS label Jul 1, 2026

openclaw-barnacle Bot added the size: S label Jul 1, 2026

mushuiyu886 mentioned this pull request Jul 1, 2026

fix(boundary-safety): guard response reads and UTF-16 truncation #97774

Closed

cxbAsDev force-pushed the fix/bound-minimax-vlm-response branch from 1864802 to 28bf119 Compare July 1, 2026 14:22

cxbAsDev closed this Jul 1, 2026

This was referenced Jul 1, 2026

fix(minimax-vlm): bound VLM API response reads #98679

Closed

fix(agents): bound MiniMax VLM JSON response reads to prevent OOM #99132

Closed

vincentkoc mentioned this pull request Jul 6, 2026

chore(jobs): prune resolved OpenClaw inbox jobs openclaw/clownfish#221

Merged

clawsweeper Bot mentioned this pull request Jul 6, 2026

fix(agents): MiniMax VLM can consume oversized success responses #100694

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(minimax-vlm): bound VLM API response reads#96264

fix(minimax-vlm): bound VLM API response reads#96264
cxbAsDev wants to merge 1 commit into
openclaw:mainfrom
cxbAsDev:fix/bound-minimax-vlm-response

cxbAsDev commented Jun 24, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 24, 2026 •

edited

Loading

Uh oh!

cxbAsDev commented Jun 24, 2026

Uh oh!

clawsweeper Bot commented Jun 24, 2026 •

edited

Loading

Uh oh!

cxbAsDev commented Jun 25, 2026

Uh oh!

clawsweeper Bot commented Jun 25, 2026 •

edited

Loading

Uh oh!

cxbAsDev commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

cxbAsDev commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Real behavior proof (required for external PRs)

Risk

Uh oh!

clawsweeper Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cxbAsDev commented Jun 24, 2026

Uh oh!

clawsweeper Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cxbAsDev commented Jun 25, 2026

Uh oh!

clawsweeper Bot commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cxbAsDev commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

cxbAsDev commented Jun 24, 2026 •

edited

Loading

clawsweeper Bot commented Jun 24, 2026 •

edited

Loading

clawsweeper Bot commented Jun 24, 2026 •

edited

Loading

clawsweeper Bot commented Jun 25, 2026 •

edited

Loading

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading