Summary

• Bound Runway video create/status JSON response parsing through the provider JSON reader instead of direct response.json().
• Added a regression test with an oversized streamed Response that verifies the stream is cancelled on overflow.
• Updated the shared provider-http test mock to expose readProviderJsonResponse for provider tests that import it from the SDK facade.
• Fixed the follow-up test helper typing so check:test-types accepts the intentional partial Response used by the overflow regression test.

What Problem This Solves

Runway video generation parsed external create and poll responses with a local helper that called response.json() directly. A successful provider response with an unbounded body could be buffered before JSON parsing, unlike the already-bounded video download path.

User Impact

• Why it matters / User impact: Users configuring Runway video generation get the same 16 MiB JSON response cap used by other provider response readers. Oversized create/status responses now fail early with a provider-owned error instead of being materialized through the native JSON reader.
• What did NOT change: The patch only changes Runway's JSON response helper, its regression test, and the shared provider-http test mock needed for SDK facade imports. It does not change request construction, polling state transitions, generated video downloads, model capabilities, auth, or provider configuration.
• Architecture / source-of-truth check: Runway's readRunwayJsonResponse remains the provider-local owner for object-shape validation, while the canonical readProviderJsonResponse contract remains the source-of-truth for provider JSON byte limits and malformed JSON wrapping.

Origin / follow-up

Follows #96604.

• Follows / completes: fix(qwen): bound video description success response reads #96604 established the same bounded response-body pattern for video description success responses.
• Gap this fills: Runway video generation still had a sibling local JSON helper reading create/status success responses through direct response.json().
• Consistency: This patch reuses the existing readProviderJsonResponse SDK facade and keeps Runway's existing object-shape validation and provider-owned malformed JSON errors.

Competition / linked PR analysis

No linked issue. Related open PR scan before implementation found no open PR touching extensions/runway/video-generation-provider.ts or matching Runway bounded JSON response reads. This PR is limited to the uncovered Runway video sibling path.

Real behavior proof

• Behavior or issue addressed: Runway video create/status success responses are read through a bounded provider JSON reader and oversized streams are cancelled.
• Real environment tested: Local OpenClaw provider runtime path in /media/vdb/code/ai/aispace/openclaw-worktrees/pr-96899, using buildRunwayVideoGenerationProvider().generateVideo() with a real streamed Response body.
• Exact steps or command run after this patch: pnpm check:test-types, node scripts/run-vitest.mjs extensions/runway/video-generation-provider.test.ts, and a local loopback HTTP proof that streams a >16 MiB provider JSON response into the production readProviderJsonResponse path.
• Evidence after fix: /media/vdb/code/ai/aispace/openclaw-pr-96899-evidence/runway-video-test-types-after-response-cast.txt, /media/vdb/code/ai/aispace/openclaw-pr-96899-evidence/runway-video-vitest-after-response-cast.txt, and /media/vdb/code/ai/aispace/openclaw-pr-96899-evidence/runway-provider-json-loopback-overflow.txt
• Observed result after fix: pnpm check:test-types completed successfully. The Runway Vitest shard reported Test Files 1 passed (1) and Tests 10 passed (10). The local loopback proof observed Runway video generation failed: JSON response exceeds 16777216 bytes, cancel_observed=true, and server close after 16,908,288 streamed bytes.
• What was not tested: Runway credential-backed network call: out of scope for this follow-up because the changed contract is the response-body reader boundary, which is exercised through the provider function with a real streamed Response.
• Fix classification: Root cause fix

Review findings addressed

• RF-001: Fixed. The oversized response fixture now uses an unknown intermediate cast for the intentional partial Response, and pnpm check:test-types passes at current head.
• RF-002: Fixed with non-mock after-fix proof. The local loopback HTTP proof streams a >16 MiB provider JSON response through the production readProviderJsonResponse path and observes overflow plus server close/cancel.
• RF-003: Fixed with the same loopback proof file: /media/vdb/code/ai/aispace/openclaw-pr-96899-evidence/runway-provider-json-loopback-overflow.txt.
• RF-004: Maintainer compatibility decision, not a repair item. Create/status metadata responses larger than the shared 16 MiB provider JSON cap now fail closed by design, and this body documents that choice.
• RF-005: Fixed. The current head passes pnpm check:test-types after making the oversized response fixture type-correct.
• RF-006: Fixed with non-mock proof beyond mocked-provider Vitest output: the loopback proof uses a real HTTP stream and the production provider JSON reader.
• RF-007: Fixed for contributor-owned actions: the type-check failure is repaired and the non-mock proof has been added; any remaining compatibility approval is a maintainer decision.
• RF-008: Fixed. The fixture now uses the narrow intentional partial Response cast accepted by TypeScript while preserving the guard that direct response.json() would fail the test.

Regression Test Plan

• Target test file: extensions/runway/video-generation-provider.test.ts
• Scenario locked in: The regression test feeds Runway's create response path an oversized streamed JSON body and asserts the provider reports Runway video generation failed: JSON response exceeds 16777216 bytes.
• Why this is the smallest reliable guardrail: The test uses the public buildRunwayVideoGenerationProvider().generateVideo() path and a real ReadableStream body with a cancel hook, so it fails if the helper regresses to direct response.json() or stops cancelling oversized streams.
• pnpm check:test-types
• node scripts/run-vitest.mjs extensions/runway/video-generation-provider.test.ts

Risk / Compatibility

Low. Successful Runway JSON responses still parse into the same typed payloads and still require top-level objects. Responses larger than 16 MiB now fail with a bounded-reader error, matching existing provider JSON response limits.

Merge risk

• Risk labels considered: merge-risk: compatibility, provider/auth surface, shared test-helper surface.
• Risk explanation: This touches a provider implementation and a shared provider-http test mock, but production behavior is limited to replacing direct JSON materialization with the existing provider JSON reader. The shared test mock change mirrors the already exported SDK facade function so provider tests can exercise the same import shape.
• Why acceptable: The runtime contract is stricter only for oversized JSON bodies. Normal JSON success payloads continue through the same Runway object validation, and malformed JSON still reports the same provider-owned malformed JSON error.
• Maintainer-ready confidence: High: the diff is small, the source-of-truth helper is reused rather than reimplemented in production code, and the regression test covers the overflow/cancel behavior at the provider function boundary. The current-head type check also passes after the partial Response cast fix.
• Patch quality notes: The broad catches are confined to the test mock's JSON reader shim to preserve the same malformed/overflow error semantics as the real provider JSON reader. No production broad catch was added. The repair commit only changes the TypeScript cast for an intentional partial test Response.

What was not changed

• Did not change Runway request construction, polling state handling, download size limits, or model capability declarations.
• Did not change any live Runway credentials or provider configuration behavior.

Root Cause

• Root cause: The source of the unbounded read was Runway's local JSON helper: it used direct response.json() for HTTP success responses instead of the shared bounded reader contract.
• Why this is root-cause fix: The helper now reads through the shared provider JSON reader contract, so every Runway create/status JSON response consumed through that helper is capped before JSON parsing while preserving existing validation semantics.