fix(gateway): bound pricing catalog streams by vincentkoc · Pull Request #95103 · openclaw/openclaw

vincentkoc · 2026-06-19T21:29:46Z

Summary

Stream gateway model-pricing catalog responses through the shared byte-cap reader instead of buffering the full body with arrayBuffer().
Preserve declared Content-Length rejection and malformed JSON/source-failure behavior.
Add a regression for a LiteLLM catalog stream with no Content-Length that crosses the 5 MiB cap and cancels the body.

Verification

node --check --experimental-strip-types src/gateway/model-pricing-cache.ts
node --check --experimental-strip-types src/gateway/model-pricing-cache.test.ts
git diff --check
autoreview: clean, no actionable findings

Proof gaps

Targeted Vitest was not run locally because this sparse Codex worktree has no node_modules and repo rules forbid installing dependencies there. Hosted validation will cover the test lane before ready/merge.

clawsweeper · 2026-06-19T21:31:08Z

Codex review: needs maintainer review before merge. Reviewed June 19, 2026, 5:41 PM ET / 21:41 UTC.

Summary
The PR changes gateway model-pricing catalog fetches to read JSON responses through readResponseWithLimit and adds a LiteLLM no-Content-Length overflow regression test.

PR surface: Source 0, Tests +65. Total +65 across 2 files.

Reproducibility: yes. from source inspection, though I did not execute a failing local repro: current main reads pricing bodies with response.arrayBuffer() before enforcing the 5 MiB cap, so a no-Content-Length stream can exceed the bound before rejection.

Review metrics: none identified.

Stored data model
Persistent data-model change detected: serialized state: src/gateway/model-pricing-cache.test.ts, serialized state: src/gateway/model-pricing-cache.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
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:

none.

Next step before merge

[P2] No repair lane is needed; the branch is the focused fix and should proceed through normal PR review and checks.

Security
Cleared: The diff only changes gateway response-body reading to an existing internal helper and adds a regression test; it does not change dependencies, workflows, secrets, package resolution, or publishing surfaces.

Review details

Best possible solution:

Land the focused stream-cap fix after normal maintainer review and required checks, keeping the shared response-limit helper as the single bounded-read path.

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

Yes from source inspection, though I did not execute a failing local repro: current main reads pricing bodies with response.arrayBuffer() before enforcing the 5 MiB cap, so a no-Content-Length stream can exceed the bound before rejection.

Is this the best way to solve the issue?

Yes; replacing the local full-body read with the existing shared bounded response helper is the narrowest maintainable fix, and it preserves declared Content-Length rejection, malformed JSON handling, and source-failure fallback behavior.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: The PR fixes bounded resource handling in a gateway background pricing fetch with limited blast radius.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a maintainer/member PR, so the external contributor real-behavior proof gate does not apply; maintainer syntax checks and a hosted exact-head CI gate were provided as validation evidence.

Evidence reviewed

PR surface:

Source 0, Tests +65. Total +65 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	5	5	0
Tests	1	65	0	+65
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	70	5	+65

What I checked:

Live PR state: Live GitHub data shows the PR is open, no longer draft, has the protected maintainer label, and is mergeable but not merged. (9c7a05cfa5ea)
Current main behavior: Current main still calls response.arrayBuffer() before checking buffer.byteLength, so no-Content-Length catalog streams are buffered before the 5 MiB rejection. (src/gateway/model-pricing-cache.ts:292, d97574aae6f2)
PR fix shape: The PR keeps the declared Content-Length precheck, then uses readResponseWithLimit with the existing source-specific overflow error text before JSON parsing. (src/gateway/model-pricing-cache.ts:290, 9c7a05cfa5ea)
Shared helper contract: readResponseWithLimit reads chunks, cancels the stream when the next chunk crosses the cap, and throws the caller-provided overflow error. (packages/media-core/src/read-response-with-limit.ts:96, d97574aae6f2)
Subpath export exists: The @openclaw/media-core/read-response-with-limit subpath is exported by the package and is already used by other runtime readers. (packages/media-core/package.json:62, d97574aae6f2)
Adjacent coverage: Current tests already cover declared oversized Content-Length handling and preserving OpenRouter fallback pricing when LiteLLM fails; the PR adds the missing streamed/no-length case. (src/gateway/model-pricing-cache.test.ts:1255, d97574aae6f2)

Likely related people:

vincentkoc: Git blame and follow-log history point to Vincent Koc for the current model-pricing cache implementation and the shared response-limit helper; the same area is touched by this focused follow-up. (role: introduced current behavior and recent area contributor; confidence: high; commits: 50614c51a85c, d97574aae6f2; files: src/gateway/model-pricing-cache.ts, src/gateway/model-pricing-cache.test.ts, packages/media-core/src/read-response-with-limit.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.

vincentkoc · 2026-06-19T21:38:27Z

Maintainer proof for 9c7a05c:

Local syntax check: node --check --experimental-strip-types src/gateway/model-pricing-cache.ts
Local syntax check: node --check --experimental-strip-types src/gateway/model-pricing-cache.test.ts
Local diff sanity: git diff --check
Autoreview: clean, no actionable findings on src/gateway/model-pricing-cache.ts or src/gateway/model-pricing-cache.test.ts
Hosted exact-head gate: CI release gate 9c7a05cfa5ea0c28c3ce5c38e81c2c342aef8e9a completed successfully: https://github.com/openclaw/openclaw/actions/runs/27849311195

Local focused Vitest was attempted with node scripts/run-vitest.mjs src/gateway/model-pricing-cache.test.ts, but this sparse Codex worktree has no node_modules; I did not install dependencies there per repo policy. The hosted release gate covered the gateway/node shards on the exact head SHA.

The runtime OpenRouter model-capability detector fetched the full /models catalog with an unbounded `await response.json()`, so a compromised or misbehaving endpoint could stream an arbitrarily large body and force the process to buffer the whole payload before parsing. Read the body through the shared bounded reader instead, capping it at 16 MiB (matching the sibling pricing-cache endpoint hardened in openclaw#95103) and cancelling the stream on overflow. This mirrors the symmetric bound-stream fixes in openclaw#95103 and openclaw#95108. Adds coverage that an oversized streamed catalog is cancelled instead of buffered and that an under-cap chunked body still reassembles, parses, and round-trips through the SQLite cache on a fresh import.

The OpenRouter /models catalog read in fetchOpenRouterModels hardened only the error/early-return path (dbd5689 cancels the body when res.bodyUsed is false), but the success branch still buffered the whole body with an unbounded `await res.json()`. The response is a provider-controlled, runtime-fetched body, so a faulty or hostile provider can stream an effectively unbounded JSON document and exhaust process memory before the parse completes; the finally-cancel is a no-op once .json() has drained. Read the success body through the canonical byte-cap reader (readResponseWithLimit) under a 4 MiB ceiling before JSON.parse, cancelling the stream on overflow and bounding idle stalls with the call's existing timeout. This is the symmetric success-path counterpart to the bounded-stream hardening landed in openclaw#95103 (pricing catalog) and openclaw#95108 (Anthropic error streams), reusing the same helper rather than a new abstraction.

* fix(agents): bound OpenRouter model catalog response reads The runtime OpenRouter model-capability detector fetched the full /models catalog with an unbounded `await response.json()`, so a compromised or misbehaving endpoint could stream an arbitrarily large body and force the process to buffer the whole payload before parsing. Read the body through the shared bounded reader instead, capping it at 16 MiB (matching the sibling pricing-cache endpoint hardened in #95103) and cancelling the stream on overflow. This mirrors the symmetric bound-stream fixes in #95103 and #95108. Adds coverage that an oversized streamed catalog is cancelled instead of buffered and that an under-cap chunked body still reassembles, parses, and round-trips through the SQLite cache on a fresh import. * fix(agents): avoid OpenRouter refetch after capped catalog miss --------- Co-authored-by: sallyom <[email protected]>

The OpenRouter /models catalog read in fetchOpenRouterModels hardened only the error/early-return path (dbd5689 cancels the body when res.bodyUsed is false), but the success branch still buffered the whole body with an unbounded `await res.json()`. The response is a provider-controlled, runtime-fetched body, so a faulty or hostile provider can stream an effectively unbounded JSON document and exhaust process memory before the parse completes; the finally-cancel is a no-op once .json() has drained. Read the success body through the canonical byte-cap reader (readResponseWithLimit) under a 4 MiB ceiling before JSON.parse, cancelling the stream on overflow and bounding idle stalls with the call's existing timeout. This is the symmetric success-path counterpart to the bounded-stream hardening landed in #95103 (pricing catalog) and #95108 (Anthropic error streams), reusing the same helper rather than a new abstraction.

…95420) * fix(agents): bound OpenRouter model catalog response reads The runtime OpenRouter model-capability detector fetched the full /models catalog with an unbounded `await response.json()`, so a compromised or misbehaving endpoint could stream an arbitrarily large body and force the process to buffer the whole payload before parsing. Read the body through the shared bounded reader instead, capping it at 16 MiB (matching the sibling pricing-cache endpoint hardened in openclaw#95103) and cancelling the stream on overflow. This mirrors the symmetric bound-stream fixes in openclaw#95103 and openclaw#95108. Adds coverage that an oversized streamed catalog is cancelled instead of buffered and that an under-cap chunked body still reassembles, parses, and round-trips through the SQLite cache on a fresh import. * fix(agents): avoid OpenRouter refetch after capped catalog miss --------- Co-authored-by: sallyom <[email protected]>

…aw#95418) The OpenRouter /models catalog read in fetchOpenRouterModels hardened only the error/early-return path (3efa98b cancels the body when res.bodyUsed is false), but the success branch still buffered the whole body with an unbounded `await res.json()`. The response is a provider-controlled, runtime-fetched body, so a faulty or hostile provider can stream an effectively unbounded JSON document and exhaust process memory before the parse completes; the finally-cancel is a no-op once .json() has drained. Read the success body through the canonical byte-cap reader (readResponseWithLimit) under a 4 MiB ceiling before JSON.parse, cancelling the stream on overflow and bounding idle stalls with the call's existing timeout. This is the symmetric success-path counterpart to the bounded-stream hardening landed in openclaw#95103 (pricing catalog) and openclaw#95108 (Anthropic error streams), reusing the same helper rather than a new abstraction.

…revent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers).

The /api/tags and /api/show discovery reads in extensions/ollama/src/provider-models.ts parsed their HTTP responses with an unbounded await response.json(). Ollama base URLs are user-supplied and can point at remote/cloud endpoints, so a hostile or buggy server (or one reachable via SSRF) could stream an unbounded or never-ending JSON body and drive model discovery into OOM. Route both reads through the shared @openclaw/media-core byte-bounded reader (readResponseWithLimit, re-exported via openclaw/plugin-sdk/response-limit-runtime) under a single 16 MiB cap before JSON.parse, cancelling the stream on overflow. Overflow throws a bounded error that the existing fail-soft handlers swallow, so a capped endpoint degrades gracefully: /api/tags returns { reachable: false, models: [] } and /api/show returns {}. Symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign. AI-assisted.

* fix(parallel): bound successful web-search JSON response reads The Parallel web_search provider parsed its /v1/search success body with an unbounded await res.json(). The body comes from an external web-search upstream, so a hostile or malfunctioning endpoint streaming an unbounded JSON payload could force the runtime to buffer the whole response before parsing, creating memory pressure or a hang on the provider path. Read the success body through the shared readProviderJsonResponse helper with a 16 MiB cap (matching the provider JSON cap from #95218); on overflow the stream is cancelled and a bounded error is thrown. The error-body path was already bounded (readResponseTextLimited, 8 KiB). Symmetric follow-up to the #95103/#95108 response-limit campaign. * docs(parallel): drop upstream PR ref from response-cap comment Replace the PR-specific '#95218' annotation with a neutral description of the shared provider JSON cap so the comment stays accurate independent of upstream PR numbering.

Exa search success responses were read via an unbounded `await response.json()`, so a misbehaving or hostile endpoint could stream an arbitrarily large body into memory before parsing. Read the success body through the shared bounded reader (16 MiB cap, the same limit other bundled providers use) and cancel the stream on overflow. This mirrors the error-body bound already in place and the #95103/#95108 response -limit campaign on the success-JSON side. AI-assisted.

* fix(ollama): bound model-discovery JSON response reads The /api/tags and /api/show discovery reads in extensions/ollama/src/provider-models.ts parsed their HTTP responses with an unbounded await response.json(). Ollama base URLs are user-supplied and can point at remote/cloud endpoints, so a hostile or buggy server (or one reachable via SSRF) could stream an unbounded or never-ending JSON body and drive model discovery into OOM. Route both reads through the shared @openclaw/media-core byte-bounded reader (readResponseWithLimit, re-exported via openclaw/plugin-sdk/response-limit-runtime) under a single 16 MiB cap before JSON.parse, cancelling the stream on overflow. Overflow throws a bounded error that the existing fail-soft handlers swallow, so a capped endpoint degrades gracefully: /api/tags returns { reachable: false, models: [] } and /api/show returns {}. Symmetric counterpart to the #95103/#95108 response-limit campaign. AI-assisted. * fix(ollama): reuse shared bounded JSON reader for model discovery Replace the local readOllamaDiscoveryJson helper with the shared readProviderJsonResponse (from openclaw/plugin-sdk/provider-http), which already enforces the 16 MiB cap, cancels the stream on overflow, and wraps malformed JSON with the caller label. The /api/tags and /api/show discovery reads now go through it directly while keeping the existing fail-soft handlers ({ reachable: false, models: [] } and {}). Add a focused regression test: when a discovery stream exceeds the JSON byte cap, fetchOllamaModels returns { reachable: false, models: [] }, queryOllamaModelShowInfo returns {}, and the bounded reader cancels the body mid-flight so less than the full advertised stream is read.

…law#96035) * fix(parallel): bound successful web-search JSON response reads The Parallel web_search provider parsed its /v1/search success body with an unbounded await res.json(). The body comes from an external web-search upstream, so a hostile or malfunctioning endpoint streaming an unbounded JSON payload could force the runtime to buffer the whole response before parsing, creating memory pressure or a hang on the provider path. Read the success body through the shared readProviderJsonResponse helper with a 16 MiB cap (matching the provider JSON cap from openclaw#95218); on overflow the stream is cancelled and a bounded error is thrown. The error-body path was already bounded (readResponseTextLimited, 8 KiB). Symmetric follow-up to the openclaw#95103/openclaw#95108 response-limit campaign. * docs(parallel): drop upstream PR ref from response-cap comment Replace the PR-specific 'openclaw#95218' annotation with a neutral description of the shared provider JSON cap so the comment stays accurate independent of upstream PR numbering.

Exa search success responses were read via an unbounded `await response.json()`, so a misbehaving or hostile endpoint could stream an arbitrarily large body into memory before parsing. Read the success body through the shared bounded reader (16 MiB cap, the same limit other bundled providers use) and cancel the stream on overflow. This mirrors the error-body bound already in place and the openclaw#95103/openclaw#95108 response -limit campaign on the success-JSON side. AI-assisted.

* fix(ollama): bound model-discovery JSON response reads The /api/tags and /api/show discovery reads in extensions/ollama/src/provider-models.ts parsed their HTTP responses with an unbounded await response.json(). Ollama base URLs are user-supplied and can point at remote/cloud endpoints, so a hostile or buggy server (or one reachable via SSRF) could stream an unbounded or never-ending JSON body and drive model discovery into OOM. Route both reads through the shared @openclaw/media-core byte-bounded reader (readResponseWithLimit, re-exported via openclaw/plugin-sdk/response-limit-runtime) under a single 16 MiB cap before JSON.parse, cancelling the stream on overflow. Overflow throws a bounded error that the existing fail-soft handlers swallow, so a capped endpoint degrades gracefully: /api/tags returns { reachable: false, models: [] } and /api/show returns {}. Symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign. AI-assisted. * fix(ollama): reuse shared bounded JSON reader for model discovery Replace the local readOllamaDiscoveryJson helper with the shared readProviderJsonResponse (from openclaw/plugin-sdk/provider-http), which already enforces the 16 MiB cap, cancels the stream on overflow, and wraps malformed JSON with the caller label. The /api/tags and /api/show discovery reads now go through it directly while keeping the existing fail-soft handlers ({ reachable: false, models: [] } and {}). Add a focused regression test: when a discovery stream exceeds the JSON byte cap, fetchOllamaModels returns { reachable: false, models: [] }, queryOllamaModelShowInfo returns {}, and the bounded reader cancels the body mid-flight so less than the full advertised stream is read.

…revent OOM (#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the #95103/#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON).

* fix(mattermost): bound successful REST JSON/text response reads The Mattermost REST client already bounds error bodies (readResponseTextLimited) and streams guarded responses without buffering, but the success path still called `await res.json()` / `await res.text()`, reading the whole body into memory before parsing. A self-hosted or compromised Mattermost server can return an arbitrarily large (or never-terminating, content-length-less) JSON/text body and force the plugin to buffer it unbounded. Read successful JSON through the shared readProviderJsonResponse (16 MiB cap, cancels the stream and throws a bounded error on overflow, same as the provider HTTP path) and cap non-JSON success bodies with readResponseTextLimited. uploadMattermostFile's file-info JSON is bounded the same way. Symmetric follow-up to the #95103 / #95108 response-limit campaign. AI-assisted. * fix(mattermost): bound probe success JSON reads * fix(mattermost): reject oversized success text bodies

…revent OOM (openclaw#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON).

…claw#96033) * fix(mattermost): bound successful REST JSON/text response reads The Mattermost REST client already bounds error bodies (readResponseTextLimited) and streams guarded responses without buffering, but the success path still called `await res.json()` / `await res.text()`, reading the whole body into memory before parsing. A self-hosted or compromised Mattermost server can return an arbitrarily large (or never-terminating, content-length-less) JSON/text body and force the plugin to buffer it unbounded. Read successful JSON through the shared readProviderJsonResponse (16 MiB cap, cancels the stream and throws a bounded error on overflow, same as the provider HTTP path) and cap non-JSON success bodies with readResponseTextLimited. uploadMattermostFile's file-info JSON is bounded the same way. Symmetric follow-up to the openclaw#95103 / openclaw#95108 response-limit campaign. AI-assisted. * fix(mattermost): bound probe success JSON reads * fix(mattermost): reject oversized success text bodies

…law#96035) * fix(parallel): bound successful web-search JSON response reads The Parallel web_search provider parsed its /v1/search success body with an unbounded await res.json(). The body comes from an external web-search upstream, so a hostile or malfunctioning endpoint streaming an unbounded JSON payload could force the runtime to buffer the whole response before parsing, creating memory pressure or a hang on the provider path. Read the success body through the shared readProviderJsonResponse helper with a 16 MiB cap (matching the provider JSON cap from openclaw#95218); on overflow the stream is cancelled and a bounded error is thrown. The error-body path was already bounded (readResponseTextLimited, 8 KiB). Symmetric follow-up to the openclaw#95103/openclaw#95108 response-limit campaign. * docs(parallel): drop upstream PR ref from response-cap comment Replace the PR-specific 'openclaw#95218' annotation with a neutral description of the shared provider JSON cap so the comment stays accurate independent of upstream PR numbering.

Exa search success responses were read via an unbounded `await response.json()`, so a misbehaving or hostile endpoint could stream an arbitrarily large body into memory before parsing. Read the success body through the shared bounded reader (16 MiB cap, the same limit other bundled providers use) and cancel the stream on overflow. This mirrors the error-body bound already in place and the openclaw#95103/openclaw#95108 response -limit campaign on the success-JSON side. AI-assisted.

* fix(ollama): bound model-discovery JSON response reads The /api/tags and /api/show discovery reads in extensions/ollama/src/provider-models.ts parsed their HTTP responses with an unbounded await response.json(). Ollama base URLs are user-supplied and can point at remote/cloud endpoints, so a hostile or buggy server (or one reachable via SSRF) could stream an unbounded or never-ending JSON body and drive model discovery into OOM. Route both reads through the shared @openclaw/media-core byte-bounded reader (readResponseWithLimit, re-exported via openclaw/plugin-sdk/response-limit-runtime) under a single 16 MiB cap before JSON.parse, cancelling the stream on overflow. Overflow throws a bounded error that the existing fail-soft handlers swallow, so a capped endpoint degrades gracefully: /api/tags returns { reachable: false, models: [] } and /api/show returns {}. Symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign. AI-assisted. * fix(ollama): reuse shared bounded JSON reader for model discovery Replace the local readOllamaDiscoveryJson helper with the shared readProviderJsonResponse (from openclaw/plugin-sdk/provider-http), which already enforces the 16 MiB cap, cancels the stream on overflow, and wraps malformed JSON with the caller label. The /api/tags and /api/show discovery reads now go through it directly while keeping the existing fail-soft handlers ({ reachable: false, models: [] } and {}). Add a focused regression test: when a discovery stream exceeds the JSON byte cap, fetchOllamaModels returns { reachable: false, models: [] }, queryOllamaModelShowInfo returns {}, and the bounded reader cancels the body mid-flight so less than the full advertised stream is read.

…revent OOM (openclaw#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON).

…claw#96033) * fix(mattermost): bound successful REST JSON/text response reads The Mattermost REST client already bounds error bodies (readResponseTextLimited) and streams guarded responses without buffering, but the success path still called `await res.json()` / `await res.text()`, reading the whole body into memory before parsing. A self-hosted or compromised Mattermost server can return an arbitrarily large (or never-terminating, content-length-less) JSON/text body and force the plugin to buffer it unbounded. Read successful JSON through the shared readProviderJsonResponse (16 MiB cap, cancels the stream and throws a bounded error on overflow, same as the provider HTTP path) and cap non-JSON success bodies with readResponseTextLimited. uploadMattermostFile's file-info JSON is bounded the same way. Symmetric follow-up to the openclaw#95103 / openclaw#95108 response-limit campaign. AI-assisted. * fix(mattermost): bound probe success JSON reads * fix(mattermost): reject oversized success text bodies

…revent OOM (openclaw#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON).

…claw#96033) * fix(mattermost): bound successful REST JSON/text response reads The Mattermost REST client already bounds error bodies (readResponseTextLimited) and streams guarded responses without buffering, but the success path still called `await res.json()` / `await res.text()`, reading the whole body into memory before parsing. A self-hosted or compromised Mattermost server can return an arbitrarily large (or never-terminating, content-length-less) JSON/text body and force the plugin to buffer it unbounded. Read successful JSON through the shared readProviderJsonResponse (16 MiB cap, cancels the stream and throws a bounded error on overflow, same as the provider HTTP path) and cap non-JSON success bodies with readResponseTextLimited. uploadMattermostFile's file-info JSON is bounded the same way. Symmetric follow-up to the openclaw#95103 / openclaw#95108 response-limit campaign. AI-assisted. * fix(mattermost): bound probe success JSON reads * fix(mattermost): reject oversized success text bodies

…revent OOM (openclaw#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON). (cherry picked from commit d577cb2)

…claw#96033) * fix(mattermost): bound successful REST JSON/text response reads The Mattermost REST client already bounds error bodies (readResponseTextLimited) and streams guarded responses without buffering, but the success path still called `await res.json()` / `await res.text()`, reading the whole body into memory before parsing. A self-hosted or compromised Mattermost server can return an arbitrarily large (or never-terminating, content-length-less) JSON/text body and force the plugin to buffer it unbounded. Read successful JSON through the shared readProviderJsonResponse (16 MiB cap, cancels the stream and throws a bounded error on overflow, same as the provider HTTP path) and cap non-JSON success bodies with readResponseTextLimited. uploadMattermostFile's file-info JSON is bounded the same way. Symmetric follow-up to the openclaw#95103 / openclaw#95108 response-limit campaign. AI-assisted. * fix(mattermost): bound probe success JSON reads * fix(mattermost): reject oversized success text bodies (cherry picked from commit 9241b97)

…revent OOM (openclaw#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON).

…claw#96033) * fix(mattermost): bound successful REST JSON/text response reads The Mattermost REST client already bounds error bodies (readResponseTextLimited) and streams guarded responses without buffering, but the success path still called `await res.json()` / `await res.text()`, reading the whole body into memory before parsing. A self-hosted or compromised Mattermost server can return an arbitrarily large (or never-terminating, content-length-less) JSON/text body and force the plugin to buffer it unbounded. Read successful JSON through the shared readProviderJsonResponse (16 MiB cap, cancels the stream and throws a bounded error on overflow, same as the provider HTTP path) and cap non-JSON success bodies with readResponseTextLimited. uploadMattermostFile's file-info JSON is bounded the same way. Symmetric follow-up to the openclaw#95103 / openclaw#95108 response-limit campaign. AI-assisted. * fix(mattermost): bound probe success JSON reads * fix(mattermost): reject oversized success text bodies

…revent OOM (openclaw#96031) * fix(nextcloud-talk): bound external send/reaction response reads to prevent OOM Nextcloud Talk talks to self-hosted servers whose HTTP responses are not trusted to be small. The send and reaction paths buffered three external bodies without any byte cap: - success JSON via await response.json() - send error text via await response.text() - reaction error text via await response.text() A hostile or misbehaving Nextcloud endpoint could stream an unbounded body (no content-length) into memory, pressuring or hanging the plugin/provider path. Cap success JSON at 16 MiB via readResponseWithLimit and collapse error bodies to an 8 KiB readResponseTextSnippet, cancelling the stream on overflow. The 'message sent but receipt JSON unreadable -> unknown' fallback is preserved (an over-limit body now also routes through the existing catch). This is the symmetric counterpart to the openclaw#95103/openclaw#95108 response-limit campaign, reusing the shared @openclaw/media-core helpers (newly re-exported from plugin-sdk/response-limit-runtime for plugin consumers). * fix(nextcloud-talk): bound error bodies via public readResponseTextLimited (no new plugin-SDK surface) Re-exporting readResponseTextSnippet from plugin-sdk/response-limit-runtime pushed the public plugin-SDK export count past its surface budget, failing plugin-sdk-surface-report.test.ts. Drop that re-export and instead bound the Nextcloud Talk send/reaction error bodies through the already-public readResponseTextLimited (openclaw/plugin-sdk/provider-http), collapsing the bounded 8 KiB prefix to a short, log-safe snippet locally. Behavior is unchanged for callers; no new plugin-SDK surface is introduced. Success JSON still reads through readResponseWithLimit (16 MiB cap). The committed bounded-response-reads Vitest suite continues to prove the caps hold against 17 MiB streamed bodies with no content-length. * fix(nextcloud-talk): reuse shared readProviderJsonResponse for send success JSON The send success receipt parsed JSON by hand via readResponseWithLimit + a local NEXTCLOUD_TALK_JSON_MAX_BYTES cap + JSON.parse(TextDecoder.decode(...)), duplicating the shared provider-http helper that the sibling room-info.ts and bot-preflight.ts already use. extensions/AGENTS.md forbids re-implementing shared helpers locally. Swap the hand-rolled block for the one-stop readProviderJsonResponse<{ ocs?: ... }>(response, "Nextcloud Talk send"), which reads through the same bounded reader and throws on overflow/malformed JSON, so the outer try/catch still keeps the "unknown" receipt and behavior is equivalent. The error path keeps readResponseTextLimited (text, not JSON). (cherry picked from commit d577cb2)

fix(gateway): bound pricing catalog streams

9c7a05c

vincentkoc self-assigned this Jun 19, 2026

openclaw-barnacle Bot added gateway Gateway runtime size: S maintainer Maintainer-authored PR labels Jun 19, 2026

vincentkoc marked this pull request as ready for review June 19, 2026 21:38

vincentkoc merged commit b073d7c into main Jun 19, 2026
245 of 252 checks passed

vincentkoc deleted the qa-sre-rpc-sdk-followup-20260619 branch June 19, 2026 21:42

This was referenced Jun 20, 2026

fix(agents): bound Google prompt cache response reads #95417

Merged

fix(agents): bound OpenRouter model-scan catalog success body #95418

Merged

fix(agents): bound OpenRouter model catalog response reads #95420

Merged

Alix-007 mentioned this pull request Jun 25, 2026

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

Merged

This was referenced Jun 25, 2026

fix(duckduckgo): bound success HTML response body read #94606

Closed

fix(volcengine): bound TTS success response text reads #95261

Closed

fix(moonshot): bound video description JSON response reads #96502

Merged

Alix-007 mentioned this pull request Jun 28, 2026

fix(cli): bound in-memory video download from provider URLs #97549

Merged

clawsweeper Bot mentioned this pull request Jun 28, 2026

fix(inworld): bound TTS audio, voices, and error response reads to prevent OOM #95416

Merged

clawsweeper Bot mentioned this pull request Jul 9, 2026

fix(gateway): cap pricing cache entries to prevent unbounded memory growth (#101543) #101713

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(gateway): bound pricing catalog streams#95103

fix(gateway): bound pricing catalog streams#95103
vincentkoc merged 1 commit into
mainfrom
qa-sre-rpc-sdk-followup-20260619

vincentkoc commented Jun 19, 2026

Uh oh!

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading

Uh oh!

vincentkoc commented Jun 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

vincentkoc commented Jun 19, 2026

Uh oh!

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

Uh oh!

Uh oh!

vincentkoc commented Jun 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Jun 19, 2026 •

edited

Loading