Origin / follow-up

Follow-up to #96505. That PR moved an OpenRouter video-catalog success JSON read from raw response.json() to the shared bounded provider JSON reader. This patch applies the same guardrail to the ClickClack REST client boundary, where successful API responses were still parsed with raw response.json().

Summary

• Route ClickClack REST success JSON responses through readProviderJsonResponse.
• Keep existing bounded error-body handling with readResponseTextLimited unchanged.
• Add a loopback HTTP regression that streams an oversized success response and verifies the client closes the stream before the full body is sent.

Maintainer-ready fields

• Behavior or issue addressed: ClickClack REST success responses crossed an external HTTP boundary through raw response.json() instead of OpenClaw's shared bounded provider JSON reader.
• Fix classification: Root cause fix
• Root cause: Root cause source: the ClickClack REST response-body contract was split because unsuccessful responses used the bounded shared reader, while the canonical success-response helper still used raw await response.json() for every 2xx JSON response from the HTTP boundary.
• Why this is root-cause fix: All ClickClack REST success methods flow through the same request<T>() helper, so changing that helper restores the response-size invariant at the boundary instead of patching individual call sites.
• Real environment tested: Local TCP loopback HTTP server plus the real ClickClack client and native fetch stream handling; no mocked Response object was used for the overflow/close proof.
• Exact steps or command run after this patch: Rebased onto current origin/main, ran the extensions Vitest shard, ran pnpm check:test-types, and ran the standalone ClickClack loopback proof script.
• Evidence after fix: The loopback server recorded error=ClickClack response: JSON response exceeds 16777216 bytes, exceeded_cap=true, and closed_before_full_response=true.
• Observed result after fix: The client rejected at the shared provider JSON cap and the server observed close at 16,908,288 bytes, before the planned 18 MiB response completed.
• What was not tested: ClickClack setup flows, plugin configuration, message delivery, and hosted business semantics remain outside this patch; the changed contract is response-body stream handling at the HTTP boundary.
• Why it matters / User impact: Oversized ClickClack success responses now fail deterministically and close early instead of being fully materialized by native JSON parsing.
• What did NOT change: Endpoint paths, request headers, auth behavior, websocket behavior, response shapes, and the existing 8 KiB error-body limit are unchanged.
• Architecture / source-of-truth check: The canonical source-of-truth for provider response-size enforcement is openclaw/plugin-sdk/provider-http; this change moves ClickClack's success JSON read onto that boundary before downstream typed response projection, matching the same shared reader pattern used by fix(openrouter): bound video catalog JSON reads #96505.
• Target test file: extensions/clickclack/src/http-client.test.ts.
• Scenario locked in: A loopback HTTP server streams an 18 MiB 200 JSON response; the real client rejects at 16 MiB and the server observes an early close.
• Why this is the smallest reliable guardrail: One shared helper return path covers every ClickClack REST success read without touching endpoint-specific behavior.
• Risk labels considered: merge-risk: low, behavior-change: oversized-provider-response, and auth-provider as a detected false-positive risk surface from editing the auth-bearing client file.
• Risk explanation: The only behavior change is for successful ClickClack JSON bodies over the shared provider cap; auth headers, URL construction, request bodies, response schemas, and websocket behavior are not changed.
• Why acceptable: Normal ClickClack REST payloads should be far below 16 MiB, and failing oversized provider responses early matches OpenClaw's existing provider response-body policy.
• Maintainer-ready confidence: High; the diff is two files, the production change is localized to the shared REST success helper, and fresh verification is bound to the rebased commit.
• Patch quality notes: Focused production diff, no repository evidence files, no unrelated cleanup, and regression coverage beside the existing bounded error-response test.

What Problem This Solves

ClickClack REST responses come from an external service boundary. Before this patch, successful responses used native response.json(), so an oversized or never-ending success body could be fully materialized before failing. The shared bounded JSON reader now enforces the existing 16 MiB provider JSON cap and cancels the stream once the cap is exceeded.

Root Cause

The ClickClack client already bounded error response text through readResponseTextLimited, but the shared REST success helper still returned await response.json(). Every successful ClickClack REST method flows through that helper, so the success path bypassed OpenClaw's provider response-size guardrail.

Why it matters / User impact

An oversized ClickClack success response can otherwise consume memory through native JSON parsing before any ClickClack-specific shape validation runs. With this change, the client fails at the provider JSON cap with a deterministic overflow error and closes the response stream early.

What did NOT change

• No ClickClack endpoint paths, request headers, auth behavior, websocket behavior, or response shapes changed.
• Error responses still use the existing 8 KiB text limit and error message format.
• No new ClickClack-specific size constant or parser was introduced.

Architecture / source-of-truth check

OpenClaw already has a shared provider response-body source of truth in openclaw/plugin-sdk/provider-http. ClickClack already used that module for bounded error text; this patch extends the same boundary helper to successful REST JSON responses instead of adding another local implementation.

Target test file

extensions/clickclack/src/http-client.test.ts

Scenario locked in

The regression starts a local HTTP server, points the real ClickClack client at it, and streams an 18 MiB success JSON response. The client rejects at the shared 16 MiB cap and the server observes the connection closing before the full response is sent.

Evidence

RED observation against the raw response.json() implementation:

AssertionError: expected [Function] to throw error including
'ClickClack response: JSON response exceeds 16777216 bytes'
but got 'Unexpected end of JSON input'

Loopback proof after the fix:

error=ClickClack response: JSON response exceeds 16777216 bytes
closed_bytes=16908288
exceeded_cap=true
closed_before_full_response=true

Real behavior proof

This proof uses a local TCP loopback HTTP server and the real ClickClack client, not a mocked Response. The server attempts to stream 18 MiB; the client rejects once the shared 16 MiB cap is exceeded, and the server's close event fires before the full body is sent.

error=ClickClack response: JSON response exceeds 16777216 bytes
closed_bytes=16908288
exceeded_cap=true
closed_before_full_response=true

Verification

Full extensions Vitest shard after rebasing onto current origin/main:

Test Files  208 passed (208)
Tests  2703 passed (2703)
[test] passed 1 Vitest shard in 333.81s

Test typecheck:

$ pnpm tsgo:test
$ pnpm tsgo:core:test && pnpm tsgo:extensions:test
$ node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo
$ node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test.tsbuildinfo

Regression Test Plan

• Exercise the real ClickClack client against a loopback HTTP server returning a 200 response with an oversized success JSON body.
• Assert the client rejects with ClickClack response: JSON response exceeds 16777216 bytes.
• Assert the server observes the stream closing after the cap is exceeded and before the full 18 MiB response is sent.
• Keep the existing error-body limit regression in place to verify the unsuccessful response path still uses readResponseTextLimited.

Why this is the smallest reliable guardrail

The ClickClack client funnels all REST success reads through one request<T>() helper. Changing that one return path covers me, workspace/channel/message reads, direct-message creation, thread replies, and realtime event polling without touching call-site behavior.

Merge risk

• Detected category: auth-provider, because the changed file is the ClickClack auth-bearing REST client.
• Compatibility: Existing auth headers, request URL construction, request bodies, websocket setup, and response shapes are unchanged.
• Related open PR scan: Fresh Alix-007 open PR comparison found no extensions/clickclack overlap; public open-PR text search for clickclack did not show a competing bounded ClickClack REST response-body PR.
• Out-of-scope boundary: This PR does not change ClickClack account setup, plugin configuration, schemas, message delivery, channel routing, or live service semantics.

Risk labels considered

• merge-risk: low
• behavior-change: oversized-provider-response
• auth-provider detected and explained above

Risk explanation

The only intentional behavior change is for successful ClickClack JSON bodies over the shared provider cap: they now fail early with a bounded-reader error instead of continuing through raw native JSON parsing. Normal ClickClack REST payloads should be far smaller than 16 MiB.

Why acceptable

This matches the existing provider-response guardrail used elsewhere in OpenClaw and avoids creating a ClickClack-specific policy. The existing error-body limit and all public client method contracts are unchanged.

Maintainer-ready confidence

High. The patch is limited to the ClickClack REST response boundary, uses the shared bounded-reader helper, and has a real loopback proof that verifies both the overflow error and early stream close.

Patch quality notes

• Production diff is one shared-reader import plus one success-path return change.
• Test diff adds the loopback oversized success-response regression beside the existing bounded error-response test.
• No repository evidence files are included in the commit.

Competition / linked PR analysis

Fresh pre-submit comparison against Alix-007 open PRs found no ClickClack file overlap. The current Alix-007 open bounded-response work covers Runway, OpenAI video, Together/Pixverse, XAI, image generation, MiniMax, FAL, Vydra, Speech, OpenRouter, embedding, Mattermost, Nextcloud, Inworld, and Discord, but no extensions/clickclack path.

A public open-PR text search for clickclack returned older docs/setup/config/channel PRs and did not show a bounded ClickClack REST response-body PR competing with this change.