fix(google): bound Veo video operation response reads by Alix-007 · Pull Request #96605 · openclaw/openclaw

Alix-007 · 2026-06-25T00:33:52Z

What Problem This Solves

The Google Veo video REST operation read in extensions/google/video-generation-provider.ts
(requestGoogleVideoJson) buffers the entire external response via an unbounded
await response.text() before checking response.ok. The Veo create/poll response is untrusted
provider content: a hostile or misconfigured endpoint can stream an arbitrarily large,
Content-Length-less body that is fully read into memory before parsing — a memory-pressure / hang
(OOM) vector on the video-generation path.

Scope is the video-generation operation JSON only. This is distinct from #96324, which covers
Google embedding/image/media/oauth/speech and does not touch video-generation-provider.ts.

Changes

Route the Veo REST operation read through the shared bounded reader readResponseWithLimit
(re-exported via openclaw/plugin-sdk/response-limit-runtime, from @openclaw/media-core)
instead of await response.text(), capped at a new GOOGLE_VIDEO_OPERATION_RESPONSE_MAX_BYTES
(16 MiB, aligned with merged provider bound-stream PRs fix(agents): bound provider JSON response reads #95218 / fix(ollama): bound model-discovery JSON response reads #96027 / fix(exa): bound untrusted search JSON response reads #96038). The result is
TextDecoder().decoded before the existing response.ok / HTTP-detail / JSON.parse flow.
On overflow the reader cancels the underlying stream and throws a bounded error
(Google video operation response exceeds 16777216 bytes). The response.ok error-detail path
and the success JSON.parse shape are otherwise unchanged.
Both create and poll share requestGoogleVideoJson (generateGoogleVideoViaRest calls it for
the :predictLongRunning create POST and for each GET <operation name> poll), so the single
bounded read covers both verbs.
No new abstraction — reuses the media-core bounded reader already used across the codebase.

Real behavior proof

Behavior addressed: The unbounded await response.text() on the Veo REST operation read let
an untrusted endpoint stream an unbounded, Content-Length-less JSON body fully into memory. The
read must instead stop at the 16 MiB cap, cancel the stream, and throw a bounded error — while
small valid operation JSON still parses unchanged.
Real environment tested: A real local node:http server (createServer) bound to
127.0.0.1, streaming a JSON operation body in 64 KiB chunks with no Content-Length header
(would total ~64 MiB, 4× the 16 MiB cap), reached over the real global fetch + real TCP
socket (not an in-process ReadableStream fixture, not a mocked fetch). The proof drives the
exact post-fix requestGoogleVideoJson read body — readResponseWithLimit(response, GOOGLE_VIDEO_OPERATION_RESPONSE_MAX_BYTES, { onOverflow }) → TextDecoder().decode →
response.ok branch → JSON.parse — against that real socket, for both the create POST and the
poll GET verbs that share the helper. readResponseWithLimit is the real @openclaw/media-core
function the changed line calls. Node v22.22.0.
Exact steps: node --import tsx proof.mts — start the real server → drive the shared read path
against POST /create-huge and GET /poll-huge (oversized, no Content-Length) and assert each
throws the bounded error + the server observed the socket aborted with bytes-on-wire ≪ the full
~64 MiB → run a negative control (the OLD unbounded read of the same body, measuring it buffers
past the cap) → drive the shared read path against small valid create/poll operation JSON and
assert they still parse.
Evidence after fix: For both create and poll, readResponseWithLimit threw
Google video operation response exceeds 16777216 bytes; the server observed the socket aborted
after ~17–18 MiB (≪ the ~64 MiB it would have sent), confirming the stream was cancelled, not
drained. Small create/poll operation JSON parsed back into intact operation objects
(name/done, and the polled done:true result with one generated sample).
Observed result (all 7 checks PASS):
- create POST shared path: overflow throws bounded error → threw, msg exceeds 16777216 bytes
- create POST shared path: stream cancelled near 16MiB → aborted=true, bytesSent=18284544 (< 33554432)
- poll GET shared path: overflow throws bounded error → threw, msg exceeds 16777216 bytes
- poll GET shared path: stream cancelled near 16MiB → aborted=true, bytesSent=17825792 (< 33554432)
- negative control: OLD unbounded read buffers PAST the 16MiB cap → buffered 16799559 bytes (> cap)
  — proves the cap is load-bearing (without it the body keeps accumulating past 16 MiB).
- happy path: small create operation JSON still parsed → name=operations/veo-abc done=false
- happy path: small poll operation JSON still parsed → done=true samples=1
What was not tested: Did not hit the live generativelanguage.googleapis.com Veo endpoint
(no key / would not reproduce a hostile oversized body); the untrusted-body behavior is fully
reproduced with a local streaming server over the same transport. The proof did not drive the read
to actual OOM — it measures bytes-on-wire + early socket abort, which is the load-bearing signal.
The proof script is not committed.

Evidence

Real node:http terminal proof (node --import tsx proof.mts):

[proof] real node:http server on http://127.0.0.1:41913, cap=16777216 bytes, would-stream≈67108864 bytes

PASS  create POST shared path: overflow throws bounded error :: threw=true msg="Google video operation response exceeds 16777216 bytes"
PASS  create POST shared path: stream cancelled near 16MiB (socket aborted, bytes ≪ 64MiB) :: aborted=true bytesSent=18284544 (< 33554432)
PASS  poll GET shared path: overflow throws bounded error :: threw=true msg="Google video operation response exceeds 16777216 bytes"
PASS  poll GET shared path: stream cancelled near 16MiB (socket aborted, bytes ≪ 64MiB) :: aborted=true bytesSent=17825792 (< 33554432)
PASS  negative control: OLD unbounded read buffers PAST the 16MiB cap (cap is load-bearing) :: buffered=16799559 bytes (> 16777216)
PASS  happy path: small create operation JSON still parsed (name, done:false) :: name=operations/veo-abc done=false
PASS  happy path: small poll operation JSON still parsed (done:true, 1 generated sample) :: done=true samples=1

[proof] 7 PASS / 0 FAIL
[proof] ALL PASS

In-repo Vitest suite for this provider (node scripts/run-vitest.mjs extensions/google/video-generation-provider.test.ts --run) — includes a streaming-fixture
regression test asserting the oversized read stops before consuming all chunks and cancels the
stream:

 Test Files  1 passed (1)
      Tests  16 passed (16)

oxlint extensions/google/video-generation-provider.ts → exit 0, clean.

This is the Google Veo video-operation counterpart to the #95103 / #95108 response-limit campaign,
applying the same @openclaw/media-core bounded reader to the remaining unbounded provider read.

Label: security

AI-assisted.

clawsweeper · 2026-06-25T00:35:16Z

Codex review: needs maintainer review before merge. Reviewed June 24, 2026, 11:21 PM ET / 03:21 UTC.

Summary
The branch routes Google Veo REST operation JSON reads through a 16 MiB bounded response reader and adds a streaming regression test for the REST fallback path.

PR surface: Source +9, Tests +60. Total +69 across 2 files.

Reproducibility: yes. Current main has an unbounded response.text() in the shared Veo REST operation helper, and the PR body gives a concrete local TCP/fetch proof path for oversized create and poll operation bodies.

Review metrics: 1 noteworthy metric.

Runtime response limit: 1 added. The PR introduces one fixed provider-runtime response ceiling that can reject operation JSON bodies current main would fully buffer.

Root-cause cluster
Relationship: canonical
Canonical: #96605
Summary: This PR is the canonical item for bounding the Google Veo operation-response read; related items are adjacent bounded-response hardening or a broader Google JSON sweep that does not touch this file.

Members:

partial_overlap: fix(google): bound JSON response reads to prevent OOM #96324 - It tracks other Google provider JSON reads but explicitly excludes video-generation-provider.ts.
adjacent_distinct: fix(agents): bound provider JSON response reads #95218 - It merged the same bounded-reader pattern for provider JSON responses in the agents HTTP helper, not the Google Veo operation helper.
adjacent_distinct: fix(ollama): bound model-discovery JSON response reads #96027 - It merged bounded discovery reads for the Ollama plugin, a similar hardening pattern on a different provider surface.
adjacent_distinct: fix(exa): bound untrusted search JSON response reads #96038 - It merged bounded Exa search JSON reads, another provider-surface precedent but not the same code path.
adjacent_distinct: fix(gateway): bound pricing catalog streams #95103 - It bounded gateway pricing catalog streams and is precedent for response-limit hardening, but it does not share the Google video code path.
1 more in the report.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
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] Maintainer should accept the 16 MiB Veo operation JSON ceiling or request a different cap before merge.

Risk before merge

[P1] A legitimate Google Veo operation JSON response larger than 16 MiB would now fail with a bounded error where current main would fully buffer and try to parse it.

Maintainer options:

Accept the 16 MiB operation cap (recommended)
Maintainers can accept 16 MiB as the intended Veo operation-metadata ceiling, matching the recent bounded provider response hardening pattern.
Tune the cap before merge
If legitimate Veo operation metadata can exceed 16 MiB, adjust the constant and keep the bounded-stream regression and real proof aligned with the chosen limit.

Next step before merge

No automated repair is queued because the remaining action is maintainer acceptance or tuning of the fixed Veo operation response cap.

Security
Cleared: The diff adds no dependencies, scripts, workflow permissions, credential handling, or package-resolution changes, and it reduces an external-response memory-pressure surface.

Review details

Best possible solution:

Land the bounded read in the Google plugin after maintainers accept or tune the 16 MiB Veo operation-metadata ceiling.

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

Yes. Current main has an unbounded response.text() in the shared Veo REST operation helper, and the PR body gives a concrete local TCP/fetch proof path for oversized create and poll operation bodies.

Is this the best way to solve the issue?

Yes, with a maintainer cap decision remaining. Reusing the existing plugin SDK bounded reader inside the Google plugin helper is the narrowest owner-boundary fix; the broader Google JSON sweep remains separate at #96324.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: The PR addresses a provider-specific memory-pressure hardening bug with limited Google video fallback blast radius.
merge-risk: 🚨 compatibility: The fixed 16 MiB cap can fail Google Veo operation responses that current main would fully buffer and parse.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster 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 proof from a real local node:http server over TCP/fetch showing bounded create and poll failures, socket cancellation near the cap, and small JSON success.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix terminal proof from a real local node:http server over TCP/fetch showing bounded create and poll failures, socket cancellation near the cap, and small JSON success.

Evidence reviewed

PR surface:

Source +9, Tests +60. Total +69 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	10	1	+9
Tests	1	60	0	+60
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	70	1	+69

What I checked:

Root policy read: Full root repository policy was read and applied; provider/plugin response behavior and compatibility-sensitive defaults are review-relevant surfaces. (AGENTS.md:1, 643410c1f3c0)
Scoped extension policy read: The scoped extensions policy was read; the PR keeps plugin code inside the Google plugin and imports the bounded reader through a plugin SDK facade. (extensions/AGENTS.md:1, 643410c1f3c0)
Current main behavior: Current main reads the REST operation body with await response.text() before status handling and JSON parsing, so create/poll operation responses are fully buffered. (extensions/google/video-generation-provider.ts:352, 643410c1f3c0)
PR bounded read: The PR replaces that read with readResponseWithLimit, a 16 MiB operation-response cap, and the existing text decode/status/JSON parse flow. (extensions/google/video-generation-provider.ts:350, e9f508fcc161)
Create and poll share helper: generateGoogleVideoViaRest calls requestGoogleVideoJson for both the :predictLongRunning create POST and the later operation poll GET path. (extensions/google/video-generation-provider.ts:386, 643410c1f3c0)
Shared reader contract: readResponseWithLimit cancels the stream when the next chunk would exceed the cap and then throws the caller-provided overflow error. (packages/media-core/src/read-response-with-limit.ts:96, 643410c1f3c0)

Likely related people:

steipete: Git history shows Peter Steinberger introduced video provider support and made follow-up Google video provider changes around video sizing and live video coverage. (role: feature introducer and primary area contributor; confidence: high; commits: 932194b7d58c, a88c6f0fe713, 79a84f070de7; files: extensions/google/video-generation-provider.ts, extensions/google/video-generation-provider.test.ts)
shakkernerd: Local blame for the current requestGoogleVideoJson helper and the current Google video provider files points to commit 9d82906. (role: recent current-main area contributor; confidence: medium; commits: 9d82906f792b; files: extensions/google/video-generation-provider.ts, extensions/google/video-generation-provider.test.ts)
velvet-shark: A recent Veo request-shape fix changed the same Google video provider files, making this a relevant adjacent routing signal. (role: recent Veo compatibility contributor; confidence: medium; commits: f2a4a5ac21d3; files: extensions/google/video-generation-provider.ts, extensions/google/video-generation-provider.test.ts)
Alix-007: Beyond this PR, this contributor authored merged bounded-response PRs for provider JSON and plugin discovery/search reads that this patch follows. (role: adjacent response-limit contributor; confidence: medium; commits: 2592f8a51a4e, d1c2934d0d17, 605aede38c10; files: src/agents/provider-http-errors.ts, extensions/ollama/src/provider-models.ts, extensions/exa/src/exa-web-search-provider.runtime.ts)
joshavant: Recent main history added the shared provider JSON response cap that this PR mirrors for the Google Veo operation helper. (role: recent response-limit maintainer; confidence: medium; commits: 0a14444924e3; files: src/agents/provider-http-errors.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.

Alix-007 · 2026-06-25T01:04:13Z

@clawsweeper review

clawsweeper · 2026-06-25T01:04:16Z

🦞🧹
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.

sallyom · 2026-06-25T17:41:07Z

Maintainer local review: merge-ready provided green CI, reviewed as a batch:

fix(qwen): bound video description success response reads #96604 - Qwen video description
fix(google): bound Veo video operation response reads #96605 - Google Veo video operation
fix(byteplus): bound video-generation success response reads #96606 - BytePlus video submit/poll
fix(github-copilot): bound usage response reads #96607 - Copilot usage
fix(voyage): bound embedding-batch status, error, and non-OK responses #96608 - Voyage embedding batch

Autoreview is clean, the 16 MiB cap is acceptable for these provider JSON/status/error/usage bodies, and the changes follow the established shared bounded-reader pattern. This is the best narrow fix for these call sites: no new SDK/API/config surface, no upgrade/backward-compatibility concern beyond the intended oversized-body failure mode, and no expected breaking behavior for normal provider responses.

openclaw-barnacle Bot added extensions: google size: S labels Jun 25, 2026

fix(google): bound video success response

e9f508f

Alix-007 force-pushed the fix/bound-google-video branch from 1aae5ff to e9f508f Compare June 25, 2026 02:35

sallyom mentioned this pull request Jun 25, 2026

fix(qwen): bound video description success response reads #96604

Merged

sallyom merged commit bfc33ac into openclaw:main Jun 25, 2026
117 of 121 checks passed

This was referenced Jun 25, 2026

fix(byteplus): bound video-generation success response reads #96606

Merged

fix(github-copilot): bound usage response reads #96607

Merged

fix(voyage): bound embedding-batch status, error, and non-OK responses #96608

Merged

github-actions Bot mentioned this pull request Jun 25, 2026

📡 Upstream Digest — 2026-06-25 18:04 UTC curtismercier/openclaw-mods#1151

Open

mushuiyu886 mentioned this pull request Jun 26, 2026

fix(google-media): bound JSON response reads #96920

Merged

github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request Jun 26, 2026

fix(google): bound video success response (openclaw#96605)

270e381

clawsweeper Bot mentioned this pull request Jun 26, 2026

fix: honor configured default agent across main paths #51762

Open

hugenshen mentioned this pull request Jun 28, 2026

fix(google): bound OAuth project and token JSON response reads #97587

Merged

QiuYuang pushed a commit to QiuYuang/openclaw that referenced this pull request Jul 1, 2026

fix(google): bound video success response (openclaw#96605)

ab62d7d

wangmiao0668000666 mentioned this pull request Jul 3, 2026

fix(ollama): bound native streaming 200 success-body NDJSON reads at 16 MiB #99585

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(google): bound Veo video operation response reads#96605

fix(google): bound Veo video operation response reads#96605
sallyom merged 1 commit into
openclaw:mainfrom
Alix-007:fix/bound-google-video

Alix-007 commented Jun 25, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 25, 2026 •

edited

Loading

Uh oh!

Alix-007 commented Jun 25, 2026

Uh oh!

clawsweeper Bot commented Jun 25, 2026 •

edited

Loading

Uh oh!

sallyom commented Jun 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

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

Uh oh!

What Problem This Solves

Changes

Real behavior proof

Evidence

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!

Alix-007 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!

sallyom commented Jun 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Alix-007 commented Jun 25, 2026 •

edited

Loading

clawsweeper Bot commented Jun 25, 2026 •

edited

Loading

clawsweeper Bot commented Jun 25, 2026 •

edited

Loading