Closes #1510 (partially — see caveat).

What I found

Reproduced the report on main. iterable() (suggested in the issue thread) did not help either — two independent problems:

1. HTTPResponse silently discards event.res.status

Pre-existing and unrelated to streaming:

app.get("/", (event) => {
  event.res.status = 201;
  return html`<p>hi</p>`;   // -> 200 ❌   (returning "hi" instead -> 201 ✅)
});

prepareResponse does res.status || preparedRes?.status, but res is the HTTPResponse and its getter was this.#init?.status || 200 — never undefined, so the staged status was dead code for every util returning an HTTPResponse (html(), iterable(), user-built ones). Same for statusText.

HTTPResponse.status / .statusText now return undefined when unset, meaning "inherit": event.res.status is used, falling back to 200. prepareResponse itself is unchanged — the || preparedRes?.status fallback finally does what it was written to do.

2. iterable() built its response before the producer ran

The ReadableStream was constructed synchronously, so toResponse had already built the Response by the time pull first ran. iterable() now awaits the first chunk before constructing the HTTPResponse — the same window v1 had, where headers went out on first write:

app.get("/", (event) =>
  iterable(async function* () {
    const data = await load();
    event.res.status = 201;
    event.res.headers.set("hello", "world");
    yield render(data);
  }),
);

Side effect: a throw before the first chunk now renders a proper error response instead of tearing a stream mid-flight.

Caveat

Returning a raw ReadableStream (the exact snippet in #1510) still cannot support this — the Response must be constructed before anything reads the stream, and eagerly priming every returned stream would stall headers for SSE/long-poll bodies. iterable() is the supported way to keep a v1-style window; documented on the util.

Breaking

• HTTPResponse.status is number | undefined (was number, always ≥ 200); statusText likewise.
• iterable() returns Promise<HTTPResponse> (as does the deprecated sendIterable). Returning it from a handler is unaffected — toResponse already awaits.

Size

Bundle budgets unchanged and still green — this comes out ~11 bytes smaller than main (dropping the || 200 / || "OK" defaults pays for the fix).

Tests added in test/status.test.ts (staged status vs. own status) and test/iterable.test.ts (status/headers before, during and after the first chunk; throw before the first chunk). Full suite + lint green.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Improved streaming responses so status codes and headers set while generating the first chunk are applied correctly.
  • Explicit response status and status text now take precedence over staged values.

• Bug Fixes

  • Corrected error handling when the first streamed chunk fails.
  • Unset response status and status text now remain unset instead of defaulting automatically.

• Documentation

  • Clarified when streaming response headers are finalized.