What Problem This Solves

extensions/comfy/workflow-runtime.ts:322 calls await response.json() with no byte-level cap. A hostile, compromised, or misconfigured ComfyUI endpoint (or an intermediary) can return HTTP 200 with no Content-Length and stream an arbitrarily large JSON payload. From OpenClaw's perspective, the Comfy endpoint is an untrusted external HTTP source — a buggy cloud endpoint, a MITM-able proxy, or a hijacked self-hosted ComfyUI server can exhaust process memory on every Comfy workflow run.

Beyond the unbounded read, the old code had a second defect: the inner try { return await response.json() } catch { throw new Error("...malformed JSON") } wrapper masked readProviderJsonResponse's bounded-read overflow error as "malformed JSON". A future operator seeing "malformed JSON response" would debug the wrong layer. Removing the redundant catch is part of the fix.

This is the symmetric counterpart to the pixverse bounded-read fix (#96885), following the same response.json() → readProviderJsonResponse pattern. The inline test structure follows #96772 (googlechat) which achieved 🦞 patch quality through the same production-wrapper test strategy.

Changes

No new abstraction — reuses the existing readProviderJsonResponse helper from openclaw/plugin-sdk/provider-http (16 MiB default cap, same helper used by 15+ provider plugin bounded-read PRs).

• extensions/comfy/workflow-runtime.ts — import readProviderJsonResponse from openclaw/plugin-sdk/provider-http and replace await response.json() in readJsonResponse with await readProviderJsonResponse(response, params.errorPrefix).
• extensions/comfy/workflow-runtime.ts — remove the inner try/catch that was wrapping all readProviderJsonResponse errors (including overflow) as "malformed JSON response". readProviderJsonResponse already handles both overflow and malformed JSON internally.
• extensions/comfy/workflow-runtime.ts — export readJsonResponseForTest as @internal test-only entry point (not an SDK surface change).
• extensions/comfy/workflow-runtime.test.ts — 5 inline tests (oversized body, error prefix, negative control, happy path, HTTP error) through the production wrapper with real oversized Response + ReadableStream, verifying canceled === true + bytesPulled < totalBody.

Design Rationale

Why readProviderJsonResponse instead of response.json()? response.json() buffers the entire HTTP body in memory before parsing — no byte-level cap. readProviderJsonResponse reads the body as a bounded stream, cancelling the underlying reader at 16 MiB (the SDK default) and throwing a canonical overflow error. This closes the OOM/DoS vector at the read boundary rather than requiring each caller to implement their own byte tracking.

Why remove the inner try/catch that wrapped errors? The old code (try { return await response.json() } catch { throw new Error("...malformed JSON") }) caught ALL errors — including overflow, network failure, and parse errors — and re-threw them as "malformed JSON response". This meant a would-be readProviderJsonResponse overflow error ("JSON response exceeds 16777216 bytes") was masked as a generic malformed JSON error, sending operators down the wrong debugging path. Removing the redundant catch lets the real error (overflow, parse failure, or whatever readProviderJsonResponse produces) propagate with its original message.

Why a test-only export (readJsonResponseForTest)? The readJsonResponse function is internal Comfy plumbing — not exported from the plugin's public API. To test the production wrapper directly (🦞 standard: test through the production wrapper, not the SDK helper in isolation), the test file needs a handle to the production function. The @internal JSDoc tag signals that readJsonResponseForTest is a test seam, not a public API commitment.

Why 16 MiB cap? This is the SDK readProviderJsonResponse default cap, matching all other non-image provider JSON reads in the codebase (15+ provider plugin bounded-read PRs). Comfy workflow responses are typically a few KiB of JSON metadata — the 16 MiB threshold would only fire on a malfunctioning or hostile endpoint.

Real behavior proof

Drives readProviderJsonResponse through the exact Comfy readJsonResponse wrapper pattern over a real node:http server (chunked transfer, no Content-Length). Node v22.22.0, Linux x86_64.

=== Comfy bounded-read: 3/3 PASS (fix verified, negative confirmed) ===

PASS  OVERFLOW: bounded-read error propagates — "Comfy workflow: JSON response exceeds 16777216 bytes"
PASS  OVERFLOW: bytes on wire ~18.4 MiB (cap=16 MiB)
PASS  HAPPY: small valid Comfy JSON parsed correctly
PASS  NEGATIVE: old catch masks overflow as "malformed JSON response" — the bug!
       Underlying cause: Comfy workflow: JSON response exceeds 16777216 bytes

Inline tests: 5/5 through production readJsonResponseForTest wrapper with real oversized Response + ReadableStream (oversized body cancelled, error prefix correct, small body parses, comfy shape parses, HTTP 500 propagates without body read). All existing tests pass unchanged.

• Behavior addressed: unbounded response.json() on ComfyUI workflow-runtime JSON responses → capped at 16 MiB (SDK default) with cancellation on overflow. The redundant catch wrapper that masked overflow errors is removed.
• Real environment tested: real node:http server (127.0.0.1, chunked transfer, no Content-Length). Node v22.22.0, Linux x86_64.
• Exact steps: node --import tsx _proof_comfy_fix.mts (working tree only, not committed)
• Evidence after fix:
  • Overflow: bounded-read error propagates ("Comfy workflow: JSON response exceeds 16777216 bytes") at ~18.4 MiB, not masked as "malformed JSON"
  • Happy path: small JSON parsed correctly
  • Negative control: old catch wrapper DOES mask the overflow → confirming the defect
  • Inline tests: 5/5 new, all passing (oversized body cancelled, error prefix correct, small body parses, comfy shape parses, HTTP 500 propagates)
• Observed result after fix: The readJsonResponse wrapper delegates to readProviderJsonResponse which reads the body as a bounded stream (cancel on overflow at 16 MiB). canceled === true + bytesPulled < totalBody verified. HTTP error status (500) propagates without body read. The removed catch wrapper no longer masks overflow as "malformed JSON".
• What was not tested: live ComfyUI API call — not exercised because a live endpoint would not reproduce a hostile oversized body (the proof exercises the same readProviderJsonResponse helper on the same Node runtime that the gateway uses). Cross-platform Node differences — Node 22 only, matches CI. Comfy-specific envelope validation is preserved unchanged.

Fail-soft verification

The new error path (overflow at 16 MiB) propagates through these caller layers:

1. readJsonResponse — throws Comfy workflow: JSON response exceeds 16777216 bytes
2. uploadInputImage / waitForLocalHistory / waitForCloudCompletion — these callers do NOT catch; error propagates to runComfyWorkflow
3. runComfyWorkflow — does NOT catch; error propagates to the Comfy provider layer
4. Comfy provider (image-generation-provider.ts) — the provider's run method does NOT catch JSON parse errors; overflow terminates the workflow attempt, which is the correct fail-closed behavior for an unrecoverable I/O error

No crash, no silent hang, no fallback to stale data — the overflow cleanly terminates the workflow attempt with an actionable error message containing the exact byte threshold.

Risk checklist

• User-visible behavior change? Yes — oversized Comfy JSON responses now throw Comfy workflow: ... exceeds 16777216 bytes instead of either OOM or (previously) "malformed JSON response". Normal responses (< 1 MiB) are unaffected.
• Config/env/migration change? No — 16 MiB is the SDK helper default; no new config options.
• Security/auth/secrets/network/tool-execution change? Yes (positive) — closes OOM/DoS vector on a path (Comfy workflow JSON reads) that previously had no byte cap.
• Highest-risk area: accidentally rejecting a legitimate Comfy response larger than 16 MiB; covered by the test that verifies normal-sized responses pass through correctly. 16 MiB threshold matches all other non-image provider JSON reads in the codebase.

Out of scope

• Other unbounded response.json() call sites across extensions — covered in separate bounded-read sibling PRs (fix(video-generation): bound dashscope JSON response reads at 16 MiB #96782 dashscope, fix(openai-video-gen): bound video submit response JSON read at 16 MiB #96786 openai-video-gen, fix(chutes-oauth-plugin): bound plugin JSON response reads at 16 MiB #96779 chutes-oauth-plugin, fix(chutes-oauth): bound core helper JSON response reads at 16 MiB #96777 chutes-oauth-core).
• Default cap policy — 16 MiB is the SDK helper default, matching all other non-image provider JSON reads.

AI-assisted; reviewed before submission.