fix(cli): keep blog adapter timeout active through body reads

[HelloOjasMutreja]

Fixes #5249.

Problem

The shared CLI blog adapter (packages/cli/api/blog/_adapter.mjs, used by both blog.list and blog.detail) had two related issues in fetchText:

1. It cleared its 15-second abort timer as soon as fetch() returned response headers, before reading the body. A response whose headers arrive promptly but whose body stream stalls afterward has no timeout protecting it, and the call hangs indefinitely.
2. It read the body via res.text(), which buffers the entire response into memory before the code ever checks the 5 MB limit. The limit rejects an oversized response only after it has already been fully read, so it doesn't actually cap how much data gets buffered.

Fix

• The abort timer is now cleared in a finally block after the read completes (success or failure), so it stays active through body consumption, not just through the initial fetch() call.
• The body is read via res.body's stream where available (getReader(), decoding chunk by chunk), checking the running decoded size after each chunk and cancelling the read as soon as it exceeds 5 MB, instead of buffering the full response first. Falls back to res.text() when a runtime or test stub doesn't expose a streamable body (rare in practice; every real fetch() response has one), still enforcing the cap after the fact in that case.

Verification

Added two regression tests matching the issue's own reproduction:

• Timeout stays active through body consumption: a stubbed fetch resolves immediately but its response body never closes. Using fake timers, advancing past the 15s timeout causes the call to reject with ERR_FETCH_FAILED rather than hang. The stub's stream reacts to the request's AbortSignal the way a real fetch response body does (rejects pending reads on abort), so this faithfully exercises the same mechanism a real network response uses.
• Size cap stops the read early: a stubbed response streams 5 chunks of 2 MB each (10 MB total) against the 5 MB cap. The call rejects with ERR_FETCH_FAILED, and the stub's pulled-chunk counter confirms fewer than all 5 chunks were consumed, proving the read stopped early rather than buffering the whole body before checking.

Both new tests fail against the pre-fix implementation (verified by temporarily reverting just the implementation file and re-running) and pass with the fix. Full blog test suite (22 tests across _adapter, blog, blog.detail, blog.list) passes. Lint required adding ReadableStream/DOMException to the CLI's ESLint global allowlist (needed by the new streaming-body test coverage; both are standard globals already implicitly relied on via fetch/AbortController). Typecheck (tsconfig.strict.json) shows no new errors; the pre-existing failures it reports are all in unrelated template/theme assets.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
astryx	Ready	Preview	Aug 31, 2026 9:32am

[github-actions]

PR Analysis Report

Preview availability: Storybook and Sandbox were not published for this CI run.

No new or modified components detected.

Bundle Size Summary

No component packages changed.

Accessibility Audit

Status: No accessibility violations detected.

---

_{Generated by PR Enrichment workflow | View full report}

[cixzhang]

Thanks, this is good. The stalled body now times out and the oversized stream stops early without changing the CLI error contract.

[Reviewed by Robohands]