fix(google-meet): bound Drive document export reads to prevent OOM by Alix-007 · Pull Request #97620 · openclaw/openclaw

Alix-007 · 2026-06-29T02:02:29Z

What Problem This Solves

Bounds the `exportGoogleDriveDocumentText` response in `extensions/google-meet/src/drive.ts` using `readProviderTextResponse`, capping at 16 MiB (fail-closed). Google Drive's files.export endpoint streams document text with no `Content-Length` header; without a cap, an attacker-controlled or unusually large document can exhaust heap.

Changed files: `extensions/google-meet/src/drive.ts` (1 line), `extensions/google-meet/src/drive.test.ts` (new)

Compatibility tradeoff: Export responses >16 MiB now throw instead of silently buffering. In practice, Drive API enforces export size limits server-side; legitimate documents will not exceed 16 MiB of plain text. Please confirm this cap is appropriate for your deployment.

Validation Evidence

Local terminal output (`node scripts/run-vitest.mjs run extensions/google-meet/src/drive.test.ts --reporter=verbose`):

```
RUN v4.1.8 /media/vdc/0668001470/workSpace/claw-campaign/openclaw

✓ |extensions| extensions/google-meet/src/drive.test.ts > exportGoogleDriveDocumentText bound > returns document text when response is within the 16 MiB cap 245ms
✓ |extensions| extensions/google-meet/src/drive.test.ts > exportGoogleDriveDocumentText bound > rejects with a size error when response exceeds 16 MiB cap (fail-closed) 48ms
✓ |extensions| extensions/google-meet/src/drive.test.ts > exportGoogleDriveDocumentText bound > negative-control: bare response.text() buffers the full oversized body (no protection) 73ms
✓ |extensions| extensions/google-meet/src/drive.test.ts > exportGoogleDriveDocumentText bound > mutation: reverted fix (bare response.text) does NOT reject over-cap body — fix is load-bearing 55ms

Test Files 1 passed (1)
Tests 4 passed (4)
Start at 12:12:28
Duration 3.08s (transform 1.77s, setup 461ms, import 1.87s, tests 428ms, environment 0ms)
```

Over-cap (17 MiB, no Content-Length): `exportGoogleDriveDocumentText` rejects with `"Google Drive files.export: text response exceeds 16777216 bytes"` before fully buffering ✓
Under-cap (256 bytes): resolves to non-empty string ✓
Negative-control: bare `response.text()` buffers >16 MiB without throwing ✓
Mutation: replacing `readProviderTextResponse` with bare `response.text()` causes the over-cap test to turn red — fix is load-bearing ✓

Security & Privacy

No user data leaves the process. The cap is fail-closed: oversized responses are rejected rather than silently accepted. No new network calls added.

Compatibility

Single-file change to `extensions/google-meet/src/drive.ts`. `readProviderTextResponse` (from `openclaw/plugin-sdk/provider-http`) defaults to 16 MiB; the function signature of `exportGoogleDriveDocumentText` is unchanged, so no existing callers are affected.

clawsweeper · 2026-06-29T02:03:57Z

Codex review: needs real behavior proof before merge. Reviewed June 28, 2026, 10:51 PM ET / 02:51 UTC.

Summary
The PR changes the Google Meet plugin's Drive files.export text read to use the shared bounded provider text reader and adds stream-size regression tests.

PR surface: Source +1, Tests +77. Total +78 across 2 files.

Reproducibility: yes. from source inspection: current main reaches response.text() for successful Drive files.export responses, which is the unbounded buffering path. I did not establish a live credentialed Google Drive export repro in this read-only review.

Review metrics: 1 noteworthy metric.

Response-size cap: 1 fail-closed 16 MiB cap added. Oversized Drive export text changes from accepted buffered body content to a caught document-body warning, so maintainers should notice the compatibility behavior before merge.

Stored data model
Persistent data-model change detected: vector/embedding metadata: extensions/google-meet/src/drive.test.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

[P1] Add redacted terminal/live output or logs showing the bounded export rejection and under-cap export path after the fix.
[P1] Get maintainer acceptance of the 16 MiB fail-closed cap or adjust the export strategy before merge.

Proof guidance:

[P1] Needs real behavior proof before merge: Mock-only: the PR body describes in-process Vitest stream tests but no redacted terminal output, live logs, or equivalent after-fix runtime proof; redact private data before posting proof, then update the PR body to trigger re-review or ask a maintainer for @clawsweeper re-review.

Risk before merge

[P1] The PR body still provides mocked/in-process Vitest evidence only; this external PR needs redacted terminal output, live logs, or equivalent after-fix runtime proof before merge.
[P1] The 16 MiB cap intentionally changes oversized successful Drive document exports from buffered document text to a caught documentTextError warning; Google documents a 10 MB files.export content limit, but maintainers should still accept that fail-closed behavior before landing. (developers.google.com)

Maintainer options:

Require real bounded-export proof (recommended)
Ask for redacted terminal/live output or logs from an after-fix setup showing the bounded export rejection and an under-cap export path before merge.
Accept the fail-closed cap
Maintainers can explicitly accept the shared 16 MiB cap because Google documents a 10 MB files.export limit, while noting that oversized bodies become artifact warnings.
Pause for a different export policy
If larger document-body support is required, pause this PR and choose a different Google Meet export strategy before changing the read path.

Next step before merge

[P1] Human review remains because the external PR needs contributor-supplied real behavior proof and maintainer acceptance of the compatibility-sensitive fail-closed cap; no narrow automation repair is currently needed.

Security
Cleared: Cleared: the diff narrows a memory-exhaustion path using an existing bounded reader and does not add dependencies, workflow changes, secrets handling, or new network destinations.

Review details

Best possible solution:

Merge the shared bounded-reader fix only after contributor-supplied redacted real runtime proof and maintainer acceptance that oversized Drive document bodies should surface as warnings.

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

Yes from source inspection: current main reaches response.text() for successful Drive files.export responses, which is the unbounded buffering path. I did not establish a live credentialed Google Drive export repro in this read-only review.

Is this the best way to solve the issue?

Yes, using the existing readProviderTextResponse helper is the narrowest maintainable plugin-boundary fix. The remaining blockers are real after-fix proof and maintainer acceptance of the fail-closed cap.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: This is a focused Google Meet plugin memory-safety bug fix with limited blast radius, but proof and compatibility acceptance remain before merge.
merge-risk: 🚨 compatibility: The PR intentionally changes oversized Drive document exports from accepted buffered text to fail-closed warning behavior for existing users.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Mock-only: the PR body describes in-process Vitest stream tests but no redacted terminal output, live logs, or equivalent after-fix runtime proof; redact private data before posting proof, then update the PR body to trigger re-review or ask a maintainer for @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +1, Tests +77. Total +78 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	2	1	+1
Tests	1	77	0	+77
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	79	1	+78

What I checked:

Current main still buffers successful Drive exports: exportGoogleDriveDocumentText on current main calls response.text() after a successful Google Drive files.export response, so the central unbounded read remains present on main. (extensions/google-meet/src/drive.ts:67, a202dd0faf56)
PR uses the existing bounded text helper: The live PR diff replaces the successful-body response.text() call with readProviderTextResponse(response, "Google Drive files.export"). (extensions/google-meet/src/drive.ts:67, 7c5b9bd0d8d9)
The helper defaults to a 16 MiB cap: readProviderTextResponse defaults to PROVIDER_TEXT_RESPONSE_MAX_BYTES, defined as 16 MiB, and throws a labeled overflow error through readResponseWithLimit. (src/agents/provider-http-errors.ts:91, a202dd0faf56)
Overflow cancels instead of continuing to buffer: readResponseWithLimit cancels the reader when the next chunk exceeds maxBytes, marks the response truncated, and throws the overflow error. (packages/media-core/src/read-response-with-limit.ts:95, a202dd0faf56)
Caller degrades to a document-body warning: attachDocumentText catches export errors and stores documentTextError, so an oversized export omits the document body while preserving the artifact path. (extensions/google-meet/src/meet.ts:644, a202dd0faf56)
Google Drive export contract supports the cap rationale: Google's official Drive API documentation says files.export returns exported byte content and that exported content is limited to 10 MB, making the PR's 16 MiB cap above the documented service limit. (developers.google.com)

Likely related people:

TurboTheTurtle: Git blame maps the current Google Meet Drive export path, caller, and bounded-response helper to commit 68b533dc9fe490aeb627a2e746cafe74b16e138e; live PR metadata for the merged change maps that author to TurboTheTurtle. (role: introduced current behavior in available history; confidence: medium; commits: 68b533dc9fe4; files: extensions/google-meet/src/drive.ts, extensions/google-meet/src/meet.ts, src/agents/provider-http-errors.ts)
vincentkoc: Live GitHub metadata shows vincentkoc merged the commit that current blame associates with the affected Google Meet path, and the current PR also contains a follow-up test-correction commit by this user. (role: merger and recent adjacent contributor; confidence: medium; commits: 68b533dc9fe4, 7c5b9bd0d8d9; files: extensions/google-meet/src/drive.ts, extensions/google-meet/src/drive.test.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.

…penclaw#97620) * fix(google-meet): bound Drive document export reads to prevent OOM * test(google-meet): return full guarded fetch result --------- Co-authored-by: Vincent Koc <[email protected]>

…penclaw#97620) * fix(google-meet): bound Drive document export reads to prevent OOM * test(google-meet): return full guarded fetch result --------- Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit 2001b15)

fix(google-meet): bound Drive document export reads to prevent OOM

388f3a4

openclaw-barnacle Bot added plugin: google-meet size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jun 29, 2026

test(google-meet): return full guarded fetch result

7c5b9bd

openclaw-barnacle Bot removed the triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. label Jun 29, 2026

vincentkoc merged commit 2001b15 into openclaw:main Jun 29, 2026
92 of 95 checks passed

Haderach-Ram mentioned this pull request Jun 29, 2026

Ecosystem Digest — 2026-06-29 Haderach-Ram/openclaw-radar#65

Open

openclaw-barnacle Bot added the triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. label Jun 29, 2026

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

🦞 OpenClaw 生态日报 2026-06-29 96loveslife/big_model_radar#74

Open

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

📡 Upstream Digest — 2026-06-29 08:51 UTC curtismercier/openclaw-mods#1172

Open

mushuiyu886 mentioned this pull request Jun 29, 2026

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

Closed

clawsweeper Bot mentioned this pull request Jun 29, 2026

fix(google-meet): bound Calendar and Meet API response reads to prevent OOM #97783

Closed

lzyyzznl mentioned this pull request Jun 30, 2026

fix(google): bound OAuth token exchange response reads to prevent OOM #98223

Closed

7 tasks

lsr911 mentioned this pull request Jul 1, 2026

fix(google-meet): bound JSON response reads to prevent OOM #98355

Closed

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

This was referenced Jul 8, 2026

fix(google-meet): bound Meet v2 + Drive files.export request deadlines #102149

Merged

fix(google-meet): bound Calendar v3 events.list request deadline #102157

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(google-meet): bound Drive document export reads to prevent OOM#97620

fix(google-meet): bound Drive document export reads to prevent OOM#97620
vincentkoc merged 2 commits into
openclaw:mainfrom
Alix-007:fix/bound-google-meet-drive

Alix-007 commented Jun 29, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 29, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

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

Uh oh!

What Problem This Solves

Validation Evidence

Security & Privacy

Compatibility

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Alix-007 commented Jun 29, 2026 •

edited

Loading

clawsweeper Bot commented Jun 29, 2026 •

edited

Loading