Generated Response body declaration rejects native iterable string chunks #8062

Summary

The generated Response constructor declaration is narrower than workerd's native body-conversion boundary. In particular, it rejects iterable string chunks that the native constructor consumes successfully. This also makes it difficult to preserve native conversion/error behavior when forwarding a genuinely unknown body from an authenticated JSON boundary without an assertion or a diagnostic suppression.

Minimal example

const response = new Response(["a", "b"]);
// Native response.text(): "ab", not "a,b".

With the generated Worker globals, string[] is not assignable to the declared BodyInit: its iterable branches admit buffers, not string chunks.

A separate instance of the same conversion-boundary question is:

function nativeBodyResponse(body: unknown): Response {
  return new Response(body);
}

The second example intentionally delegates successful conversion and native throws to workerd; it does not promise that every input constructs successfully. Replacing it with String(body), JSON serialization, or an input-rejection guard changes observable behavior, especially for iterables. Broadening only the iterable member would help the first example but would not describe this raw conversion entry point.

Observed runtime and version limits

I have exercised the direct native constructor through a real workerd handler using workerd 1.20261012.1, compatibility date 2026-08-30: the string-chunk example yields ab. The same fixture also checks string/scalar/native-error behavior. This is not a claim that I executed the newly published October 28 binary.

I separately inspected the currently published workerd 1.20261028.1, @cloudflare/workers-types 5.20261028.1 (both stable and experimental declarations), and Wrangler 4.154.0's workerd dependency 1.20261023.1. Their declarations/source retain the mismatch; merely updating these packages does not change this constructor signature.

Owning source

Pinned source at b986e5c477f552f4489469aac39a3ecf9ef2bc4c:

• src/workerd/api/http.h:55–62: native initializer includes AsyncGeneratorIgnoringStrings<jsg::Value>.
• src/workerd/api/http.c++:89–107: iterator body extraction delegates to native JsReadableStream::from.
• src/workerd/api/http.h:120–124: the TypeScript BodyInit iterable branches are buffer-only.
• src/workerd/api/http.h:1188–1192: Response's existing override is constructor(body?: BodyInit | null, init?: ResponseInit).

This override flows through the ordinary workerd type worker and the class-to-interface transform into both generated ambient and importable constructors. wrangler types consumes that producer; manually editing its output is not a durable correction.

Related documentation: iterables as request/response bodies and generating Worker types.

Requested correction / clarification

Could the generated Response input contract reflect this native conversion boundary? A constructor-only body?: unknown declaration would let native conversion remain authoritative while preserving the constrained ResponseInit, Response result, two optional parameter slots, Request constructor and shared BodyInit uses. That is a proposed direction, not a request to hand-edit generated output or claim all values are valid.

If the intentionally supported declaration should be narrower, please clarify the supported, behavior-preserving way to forward a raw body to the direct native constructor, and how iterable string chunks should be represented. No application runtime wrapper or altered conversion is needed to reproduce the mismatch.