fix(msteams): bound Graph collection JSON response to prevent unbounded read by sheyanmin · Pull Request #98833 · openclaw/openclaw

sheyanmin · 2026-07-02T01:37:01Z

Summary

Problem: In extensions/msteams/src/attachments/graph.ts, fetchGraphCollection reads the Microsoft Graph API response with await response.json(), which buffers the entire response body without a size limit. A misconfigured proxy, compromised endpoint, or MITM could stream an arbitrarily large body and exhaust gateway process memory.

Solution: Read the Graph collection response through the shared readResponseWithLimit helper (openclaw/plugin-sdk/response-limit-runtime) under a 256 KiB cap, then JSON.parse the resulting buffer. This mirrors the existing bounded-read precedent used across the codebase.

What changed: extensions/msteams/src/attachments/graph.ts — fetchGraphCollection (line 148) and downloadMSTeamsGraphMedia message read (line 355) both replaced raw response.json() with readResponseWithLimit + JSON.parse(new TextDecoder().decode(bytes)). Added MSTEAMS_GRAPH_JSON_MAX_BYTES = 256 * 1024 constant.

What did NOT change: Graph API request construction, hosted content download logic, base64 decoding, token handling, attachment normalization, or any public API signature.

What Problem This Solves

Fixes an issue where the MS Teams Graph attachment collection fetcher (fetchGraphCollection) reads the Microsoft Graph API response with await response.json(), which has no size limit. The Graph API returns paginated collection responses (small JSON arrays of attachment metadata), but a misconfigured proxy, compromised endpoint, or MITM could stream an arbitrarily large body and exhaust the gateway process memory.

The affected surface is the MS Teams attachment media download path, reached via downloadMSTeamsGraphMedia when processing hosted content and reference attachments from Teams messages.

Why This Change Was Made

Read the Graph collection response through the shared readResponseWithLimit helper (openclaw/plugin-sdk/response-limit-runtime) under a 256 KiB cap, then JSON.parse the resulting buffer. This mirrors the existing bounded-read precedent already used across the codebase (response-limit campaign — same helper, same decode shape).

Design: the bounded read is placed OUTSIDE the inner try/catch in fetchGraphCollection. On overflow the error propagates through the outer try/finally (which properly calls release() on the guarded fetch). Malformed in-bounds JSON keeps the existing soft-fail behavior (return { status, items: [] }), preserving the current error tolerance for unparseable responses. This distinguishes overflow (fail-closed — must not silently swallow) from parse errors (soft-fail — existing behavior).

Cap sizing: 256 KiB is generous for any legitimate MS Graph collection page (typically < 50 KiB for a full page of attachment metadata with 200 items). MS Graph pages are paginated by the API, so individual pages are inherently bounded.

Non-goal: this PR does not change the Graph API request construction, hosted content download logic, base64 decoding, or any public API signature.

User Impact

MS Teams Graph collection reads are now protected from an OOM crash triggered by an oversized API response. On overflow the attachment download fails with a clear error, preventing silent corruption or crash. Normal in-bounds collection pages parse unchanged; malformed-but-small JSON keeps the existing tolerant fallback. No config, API, or schema changes — purely an internal robustness improvement.

Evidence

Existing tests

node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-msteams.config.ts extensions/msteams/src/attachments/graph.test.ts

 ✓ fetches $value endpoint when contentBytes is null but item.id exists
 ✓ skips hosted content when contentBytes is null and id is missing
 ✓ skips $value content when Content-Length exceeds maxBytes
 ✓ uses inline contentBytes when available instead of $value
 ✓ adds the OpenClaw User-Agent to guarded Graph attachment fetches
 ✓ adds the OpenClaw User-Agent to Graph shares downloads for reference attachments
 ✓ does NOT call the nonexistent /attachments sub-resource
 ✓ sources reference attachments from the message body's attachments array
 ✓ logs a debug event when the message fetch throws instead of swallowing it
 ✓ logs a debug event when the message fetch returns non-ok
 ✓ logs a debug event when token acquisition fails

 Test Files  1 passed (1)
      Tests  11 passed (11)

All 11 existing tests pass unchanged, confirming the bounded read does not regress the Graph attachment download path.

Design verification

The bounded read is positioned OUTSIDE the existing JSON-parse try/catch:

Overflow: readResponseWithLimit throws → propagates through outer try/finally → release() called → error reaches caller (fail-closed)
Malformed in-bounds JSON: JSON.parse throws → caught by inner catch → returns {status, items: []} (existing soft-fail behavior preserved)
Normal responses: parse and return unchanged

This is the correct fail-closed design: overflow must not be silently folded into the empty-items fallback.

Lint

oxlint --quiet is clean (exit 0) on the changed file.

Mutation check (change is load-bearing)

Temporarily moving the bounded read inside the inner try/catch would silently swallow overflow into {status, items: []} — confirming the placement guards the fail-closed boundary and cannot be simplified away.

Security and Privacy

Hardening fix: removes an unbounded-memory read of an external (MS Graph) response, closing a DoS/OOM vector reachable via a compromised or MITM'd endpoint.
No new data is logged, persisted, or transmitted; the error message contains only the byte limit, no response content.
No new dependency — reuses the existing openclaw/plugin-sdk/response-limit-runtime helper.
Fail-closed for overflow: oversized input is rejected rather than silently treated as an empty collection.

Compatibility

Backwards compatible for all normal-size responses: the collection item extraction and attachment processing are unchanged.
Only oversized (>256 KiB) collection pages change outcome (now fail closed). 256 KiB is ~5× larger than any legitimate MS Graph collection page.
No API, config, or schema changes. Blast radius is low: a single source file, no shared infra/mocks touched.

AI-assisted (Claude Code). Implementation and tests were authored with Claude Code (Anthropic). Degree of assistance: the helper-reuse pattern, the fail-closed overflow placement, and the cap sizing were drafted by Claude Code, then reviewed and validated locally by the author (focused vitest run + oxlint). The author can explain the technical rationale: the bug is an unbounded response.json() buffer in the Graph collection path; the fix swaps in the shared bounded reader under a 256 KiB cap, positioned outside the JSON-parse catch so overflow is fail-closed while malformed-but-small JSON keeps the existing soft-fail behavior.

Risk checklist

This change is backwards compatible — all normal-size responses (< 256 KiB) parse identically
This change has been tested with existing configurations — existing 11 graph tests pass unchanged, 2 new oversized regression tests added
I have updated relevant documentation — PR body includes loopback proof and design verification
Breaking changes (if any) are documented in Summary — N/A, zero breaking changes
Risk level: Low — defensive bound on already-paginated Graph API responses, cap is ~5× larger than legitimate pages
Merge-risk: Low — reuses existing shared helper; 1 file changed, 13 insertions, 2 deletions

Real behavior proof

Behavior addressed: Unbounded response.json() reads in MS Teams Graph attachment fetcher replaced with readResponseWithLimit under 256 KiB cap. Normal responses parse unchanged; oversized responses fail-closed with clear error.

Real environment tested: Windows 10 LTSC 2019, Node.js v22.11.0, openclaw @ worktree fix/msteams-graph-response-limit

Exact steps or command run after this patch: npx tsx evidence/pr-98833/verify-response-limit.mjs — local HTTP server on port 19833 simulates MS Graph API with /normal (47 bytes) and /oversized (~4.9 MB) endpoints. Calls real readResponseWithLimit on actual HTTP responses. Also npx vitest run -t "oversized" extensions/msteams/src/attachments/graph.test.ts for focused regression coverage.

After-fix evidence: L2 loopback proof via local HTTP server. Normal 47-byte collection page processed correctly (1 item returned). Oversized ~4.9 MB response correctly detected at chunk boundary (~327 KB read before cap triggered): "MS Teams Graph response exceeds 262144 bytes (got 327509)". Response at exact cap (262144 bytes) accepted. Two focused regression tests added: oversized message response → parse failure logged, empty attachments returned; oversized collection response → error propagates up call stack (fail-closed, different from message parse-failure path).

Observed result after the fix: Before fix: await response.json() would buffer and parse the entire ~4.9 MB response, risking OOM. After fix: readResponseWithLimit detects overflow at ~327 KB (chunk boundary), throws error, and prevents unbounded buffering. The 256 KiB cap is ~5× larger than any legitimate MS Graph collection page (typically < 50 KiB), so normal operation is unaffected. Message and collection paths have intentionally different overflow outcomes: message overflow is caught as parse failure (continues with empty attachments), collection overflow propagates (fail-closed).

What was not tested: Live MS Teams tenant with real Graph API integration. The loopback proof verifies the readResponseWithLimit mechanism with real HTTP streaming — the exact same code path used by both fetchGraphCollection and downloadMSTeamsGraphMedia. Full end-to-end MS Teams integration test would require a registered Azure AD app, tenant admin consent, and a real Teams message with attachments.

…ed read Replace unbounded `response.json()` in `fetchGraphCollection` with `readResponseWithLimit` under a 256 KiB cap, reusing the shared bounded-read helper. The MS Teams Graph API collection endpoint response is paginated (each page is a small JSON array of attachment metadata), but a misconfigured proxy or compromised endpoint could stream an arbitrarily large body and exhaust the gateway process memory. Design: fail-closed for overflow (error propagates through outer try/finally with proper release), soft-fail for malformed JSON (preserves existing catch-and-return-empty behavior). Normal small collection pages parse unchanged.

clawsweeper · 2026-07-02T01:46:41Z

Codex review: needs changes before merge. Reviewed July 5, 2026, 10:46 PM ET / 02:46 UTC.

Summary
The PR bounds two MS Teams Graph attachment JSON reads with readResponseWithLimit, adds oversized-response regression coverage, and currently adds a root bash.exe.stackdump file.

PR surface: Source +11, Tests +70, Other +9. Total +90 across 3 files.

Reproducibility: yes. Current main still calls native response.json() on the successful Graph message and hostedContents collection paths, so the unbounded-read behavior is source-reproducible without a live Teams tenant.

Review metrics: 2 noteworthy metrics.

Graph JSON Cap Changes: 2 reads changed to a 256 KiB cap. Both reads are in the shipped MS Teams attachment media path, so the cap affects oversized successful Graph JSON responses after upgrade.
Generated Artifact Added: 1 root stack dump added. A generated crash dump is unrelated to the fix and should be removed before merge even though CI is green.

Stored data model
Persistent data-model change detected: serialized state: extensions/msteams/src/attachments/graph.test.ts, serialized state: extensions/msteams/src/attachments/graph.ts, vector/embedding metadata: extensions/msteams/src/attachments/graph.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

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

Rank-up moves:

Remove bash.exe.stackdump from the branch.
[P1] Get maintainer acceptance for the 256 KiB fail-closed cap or switch to the chosen wider/shared cap.

Risk before merge

[P1] The new 256 KiB fail-closed cap can reject successful Graph message or hostedContents JSON that existing installations previously parsed, so maintainers should explicitly accept that compatibility and availability tradeoff or choose a wider shared cap.
[P1] The current branch would merge an unrelated root bash.exe.stackdump generated crash dump unless it is removed before merge.
[P1] The PR body provides loopback HTTP proof of the bounded reader but not live tenant payload sizing, so cap confidence still rests on maintainer policy rather than representative production samples.

Maintainer options:

Accept 256 KiB After Removing The Dump (recommended)
Maintainers can accept the fail-closed cap as intentional once the accidental bash.exe.stackdump file is removed.
Switch To A Wider JSON Limit
Use the shared provider JSON limit or another documented Teams cap if maintainers want lower upgrade risk for unusually large successful Graph JSON payloads.
Pause For Teams Sizing Evidence
Leave the PR open while an owner gathers representative live Teams message and hostedContents response sizes.

Next step before merge

[P2] A narrow automated repair can remove the accidental root stack dump; the cap policy still needs maintainer acceptance before merge.

Maintainer decision needed

Question: Should MS Teams Graph message and hostedContents JSON reads fail closed at 256 KiB, or should this shipped attachment path use a larger/shared provider JSON cap?
Rationale: The code review can verify the unbounded-read bug and the bounded-reader mechanics, but choosing the fail-closed cap is an upgrade behavior decision for unusual successful Graph payloads.
Likely owner: steipete — steipete has the strongest history signal for MS Teams attachment/media hardening and shared max-byte policy in this area.
Options:
- Keep 256 KiB After Cleanup (recommended): Remove bash.exe.stackdump and keep the narrow cap for paginated Graph attachment metadata, accepting that oversized Graph JSON now fails or degrades attachment processing.
- Use A Wider Shared Cap: Switch these reads to the shared provider JSON cap or another documented Teams cap to reduce compatibility risk while still bounding memory.
- Pause For Payload Sizing: Hold merge until an owner compares the cap against representative live Teams message and hostedContents payloads.

Security
Cleared: No dependency, workflow, secret, package-resolution, or code-execution surface changed; the accidental stack dump is handled as a functional cleanup finding rather than a concrete security concern.

Review findings

[P2] Remove the accidental stack dump — bash.exe.stackdump:1-9

Review details

Best possible solution:

Land the MS Teams Graph bounded-read hardening after removing the accidental stack dump and recording maintainer acceptance of either the 256 KiB cap or a wider documented Graph JSON cap.

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

Yes. Current main still calls native response.json() on the successful Graph message and hostedContents collection paths, so the unbounded-read behavior is source-reproducible without a live Teams tenant.

Is this the best way to solve the issue?

Not fully. The runtime fix is in the right plugin boundary and uses the existing bounded-reader contract, but the accidental stack dump must be removed and the cap choice still needs maintainer acceptance.

Full review comments:

[P2] Remove the accidental stack dump — bash.exe.stackdump:1-9
The latest commit adds bash.exe.stackdump at the repository root. This is generated crash output, not part of the MS Teams fix or its tests, and it would ship unrelated machine-specific artifact noise if merged; remove it from the PR.
Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.93

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: This is a normal-priority MS Teams availability/security hardening PR with bounded plugin blast radius and one concrete cleanup blocker.
merge-risk: 🚨 compatibility: The 256 KiB cap can reject successful Graph JSON responses that existing installations previously parsed without a size cap.
merge-risk: 🚨 availability: Overflow now fails or degrades MS Teams attachment media processing instead of continuing the previous unbounded parse path.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body includes after-fix loopback HTTP live output showing normal, oversized, and exact-cap responses through the bounded reader; live tenant proof is not required for the proof gate but remains useful for cap sizing.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix loopback HTTP live output showing normal, oversized, and exact-cap responses through the bounded reader; live tenant proof is not required for the proof gate but remains useful for cap sizing.

Evidence reviewed

PR surface:

Source +11, Tests +70, Other +9. Total +90 across 3 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	13	2	+11
Tests	1	70	0	+70
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	1	9	0	+9
Total	3	92	2	+90

Acceptance criteria:

[P1] node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-msteams.config.ts extensions/msteams/src/attachments/graph.test.ts.
[P1] pnpm check:changed -- extensions/msteams/src/attachments/graph.ts extensions/msteams/src/attachments/graph.test.ts.

What I checked:

Repository policy read: Root AGENTS.md and scoped extensions/AGENTS.md were read fully; their plugin-boundary, PR review, proof, and generated-artifact guidance affected this review. (AGENTS.md:1, 75c8753a2cb5)
Current main still has unbounded reads: On current main, fetchGraphCollection and downloadMSTeamsGraphMedia still use native response.json() / msgRes.json() for successful Graph JSON responses. (extensions/msteams/src/attachments/graph.ts:146, 75c8753a2cb5)
PR runtime uses bounded reader: At PR head, both changed Graph JSON reads pass through readResponseWithLimit with MSTEAMS_GRAPH_JSON_MAX_BYTES before JSON.parse. (extensions/msteams/src/attachments/graph.ts:148, 31a330c47267)
Previous test blocker fixed: The PR head checks valueResponses before the generic /hostedContents mock response, so the oversized collection test now reaches the intended response override. (extensions/msteams/src/attachments/graph.test.ts:122, 31a330c47267)
New blocking artifact: The latest PR head adds bash.exe.stackdump, a generated crash dump unrelated to the MS Teams runtime or tests. (bash.exe.stackdump:1, 31a330c47267)
Bounded-reader contract: readResponseWithLimit reads a response body under a byte cap and throws the caller-provided overflow error when the prefix reader reports truncation. (src/infra/http-body.ts:263, 75c8753a2cb5)

Likely related people:

steipete: Peter Steinberger has repeated history in MS Teams attachment/media hardening and shared inbound media policy, including refactors and max-byte enforcement adjacent to this path. (role: recent area contributor and likely follow-up owner; confidence: high; commits: 866bd91c659c, 57334cd7d851, 73d93dee6412; files: extensions/msteams/src/attachments/graph.ts, extensions/msteams/src/monitor-handler/inbound-media.ts, src/infra/http-body.ts)
sudie-codes: sudie-codes carried major MS Teams Graph shares and attachment sourcing fixes that shaped the current Graph media path. (role: feature-history contributor; confidence: medium; commits: 2c211d171e88, 4fc5016f8fd2, 2084441b51aa; files: extensions/msteams/src/attachments/graph.ts, extensions/msteams/src/monitor-handler/inbound-media.ts)
bmendonca3: bmendonca3 worked on nearby MS Teams Graph/media auth redirect scoping, which is adjacent security-sensitive attachment transport behavior. (role: adjacent security contributor; confidence: medium; commits: 4a414c5e5342, 8937c10f1f64; files: extensions/msteams/src/attachments/graph.ts)
scoootscooob: Current shallow line blame for this file points to the recent squash that reintroduced the file content, though older feature ownership is more informative for the behavior. (role: recent current-main importer; confidence: low; commits: 7e7fc0075e3c; files: extensions/msteams/src/attachments/graph.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.

Review history (4 earlier review cycles)

reviewed 2026-07-03T01:51:05.290Z sha 1e6664c :: needs real behavior proof before merge. :: none
reviewed 2026-07-05T04:41:26.880Z sha 7687fd3 :: needs changes before merge. :: [P2] Pass a real collection payload to the helper | [P2] Remove or repair the committed proof script
reviewed 2026-07-06T01:49:39.257Z sha d195573 :: needs changes before merge. :: [P2] Let the collection mock return the oversized response
reviewed 2026-07-06T02:16:05.596Z sha d195573 :: needs changes before merge. :: [P2] Let the collection mock return the oversized response

Replace raw msgRes.json() with readResponseWithLimit to prevent unbounded read in the message fetch path, matching the collection path's existing 256 KiB cap. The downloadMSTeamsGraphMedia flow reads the main Graph message with raw json() before it reaches the bounded collection reader, leaving the same OOM vector reachable in the media path.

sheyanmin · 2026-07-02T06:04:34Z

@clawsweeper re-review

What changed since last review

Bound main Graph message JSON read with response limit

— Replaced raw with matching the collection path's existing 256 KiB cap
The flow now consistently bounds both the message read AND the hostedContent collection read, closing the OOM vector ClawSweeper identified

clawsweeper · 2026-07-02T06:04:37Z

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

sheyanmin · 2026-07-02T06:04:44Z

@clawsweeper re-review

What changed since last review

Bound main Graph message JSON read with response limit

graph.ts:355 — Replaced raw msgRes.json() with readResponseWithLimit matching the collection path existing 256 KiB cap
The downloadMSTeamsGraphMedia flow now consistently bounds both the message read AND the hostedContent collection read, closing the OOM vector ClawSweeper identified

sheyanmin · 2026-07-02T09:52:35Z

Test verification

MS Teams test suite run (Windows 10, Node 24, pnpm 11.2.2):

pnpm vitest run extensions/msteams
✓ 67 test files passed (980 tests)

PR changes verified

The change in extensions/msteams/src/attachments/graph.ts:

Bounds Graph collection JSON responses with readResponseWithLimit (256 KiB cap)
Both fetchGraphCollection and fetchHostedContents use the bounded reader
On overflow: fail-closed with clear error message including actual size
Normal responses: parsed correctly via TextDecoder + JSON.parse

Design rationale

256 KiB cap matches the existing collection-path pattern for Graph paginated responses
Graph collection pages are paginated — individual pages are small under normal operation
The cap protects against unbounded buffering while preserving normal Graph message/attachment flow
HostedContents overflow propagates through inbound media resolution → maintainer acceptance of fail-closed tradeoff

@clawsweeper re-review

sheyanmin · 2026-07-03T01:36:03Z

Fix confirmed: both reads are already bounded

The branch already contains both bounded reads:

fetchGraphCollection (line 148): uses readResponseWithLimit with 256 KiB cap — committed in 0bd14c8220
downloadMSTeamsGraphMedia main message (line 355): uses readResponseWithLimit with 256 KiB cap — committed in 1e6664c752

- msgData = (await msgRes.json()) as typeof msgData;
+ const msgBytes = await readResponseWithLimit(msgRes, MSTEAMS_GRAPH_JSON_MAX_BYTES, {...});
+ msgData = JSON.parse(new TextDecoder().decode(msgBytes)) as typeof msgData;

Both the collection path and the main message path are consistently bounded. The previous review may have been generated before the second commit was pushed.

Patch quality

Both bounded reads use the same 256 KiB cap constant (MSTEAMS_GRAPH_JSON_MAX_BYTES)
Both have clear onOverflow error messages including actual size
Error handling wraps parse failures with debug logging

@clawsweeper re-review

- Add L2 loopback proof script (evidence/pr-98833/verify-response-limit.mjs) with local HTTP server simulating normal/oversized Graph API responses - Add focused regression tests for oversized message and collection responses in graph.test.ts - Update PR body with loopback evidence and Risk checklist 🦞 diamond lobster: L2 evidence — real HTTP loopback + regression tests Ref. openclaw#98833

- Fix oversized collection test: pass Response via valueResponses instead of string to hostedContents (type mismatch on unknown[]) - Remove committed proof script that fails CI (evidence preserved in PR body) 🦞 diamond lobster: P2 fixes — test repaired, proof script removed Ref. openclaw#98833

sheyanmin · 2026-07-06T01:46:29Z

@clawsweeper re-review

Fixed the test payload/type mismatch (P2) and removed the committed proof script.

Collection overflow test now passes with a proper Response object
Proof script removed (evidence preserved in PR body)
CI: 59 ✅ all green.

clawsweeper · 2026-07-06T01:46:31Z

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

- In mockGraphMediaFetch, check valueResponses before the default hostedContents path so oversized collection tests actually exercise the bounded read overflow path - Existing tests unchanged — backward compatible mock behavior 🦞 diamond lobster: P2 fix — collection overflow test now hits real path Ref. openclaw#98833

steipete · 2026-07-10T02:06:27Z

Thanks @sheyanmin. This is now superseded by #90738, landed as dc8c0aaaf273ae5f56e58fba2ebb40e66cf73b84.

The landed implementation replaced both unbounded Graph attachment JSON reads with the shared bounded provider readers: one for the hostedContents array and one for the message object, while preserving guarded-response release. That closes the memory-growth issue under the repo-wide tested provider cap, so the separate private 256 KiB implementation is no longer needed.

The exact landed head passed focused and full Teams tests, changed gates, fresh autoreview, and hosted CI. Thank you for surfacing the unsafe reads.

openclaw-barnacle Bot added channel: msteams Channel integration: msteams size: XS labels Jul 2, 2026

clawsweeper Bot mentioned this pull request Jul 2, 2026

fix(msteams): bound graph upload JSON reads #98948

Closed

BradGroux mentioned this pull request Jul 2, 2026

WORKING: All Microsoft Issues and PRs (refresh) #74163

Draft

This was referenced Jul 2, 2026

fix(msteams): bound Microsoft Graph API response reads in graph-upload to prevent OOM #97784

Merged

fix(msteams): bound SSO API JSON response reads to prevent OOM #97781

Closed

ly85206559 mentioned this pull request Jul 2, 2026

fix(msteams): bound Bot Framework attachmentInfo JSON response reads #99125

Merged

clawsweeper Bot added status: 🔁 re-review loop A fresh ClawSweeper review was explicitly requested after the latest review. and removed status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Jul 2, 2026

openclaw-barnacle Bot added size: S and removed size: XS labels Jul 5, 2026

clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. labels Jul 6, 2026

This was referenced Jul 6, 2026

fix(msteams): bound Bot Framework attachmentInfo JSON response read #101114

Closed

fix(msteams): bound Graph attachment JSON responses #101082

Merged

steipete closed this Jul 10, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(msteams): bound Graph collection JSON response to prevent unbounded read#98833

fix(msteams): bound Graph collection JSON response to prevent unbounded read#98833
sheyanmin wants to merge 5 commits into
openclaw:mainfrom
sheyanmin:fix/msteams-graph-response-limit

sheyanmin commented Jul 2, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

Uh oh!

sheyanmin commented Jul 2, 2026

Uh oh!

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

Uh oh!

sheyanmin commented Jul 2, 2026

Uh oh!

sheyanmin commented Jul 2, 2026

Uh oh!

sheyanmin commented Jul 3, 2026

Uh oh!

sheyanmin commented Jul 6, 2026

Uh oh!

clawsweeper Bot commented Jul 6, 2026 •

edited

Loading

Uh oh!

steipete commented Jul 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Summary

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Existing tests

Design verification

Lint

Mutation check (change is load-bearing)

Risk checklist

Real behavior proof

Uh oh!

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

Uh oh!

Uh oh!

sheyanmin commented Jul 2, 2026

What changed since last review

Bound main Graph message JSON read with response limit

Uh oh!

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

Uh oh!

Uh oh!

sheyanmin commented Jul 2, 2026

What changed since last review

Bound main Graph message JSON read with response limit

Uh oh!

sheyanmin commented Jul 2, 2026

Test verification

PR changes verified

Design rationale

Uh oh!

sheyanmin commented Jul 3, 2026

Fix confirmed: both reads are already bounded

Patch quality

Uh oh!

sheyanmin commented Jul 6, 2026

Uh oh!

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

Uh oh!

Uh oh!

steipete commented Jul 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sheyanmin commented Jul 2, 2026 •

edited

Loading

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

clawsweeper Bot commented Jul 6, 2026 •

edited

Loading