🐛 Bug Report — Runtime APIs: a string chunk in a fetch() request body silently sends an empty body with typescript_implemented_streams #8041

Activity

1. james-elicx commented on Oct 27, 2026

   

   james-elicx

   on Oct 27, 2026

   MemberAuthor

   More actions

   A correction to "Response bodies are not affected" above: that holds for reading a response in JavaScript (text() etc. reject on both implementations). A Response that the fetch handler returns to the client is affected. With the C++ implementation, string chunks in it are sent UTF-8 encoded. With typescript_implemented_streams, the client gets an empty reply: no status line, and the bytes enqueued before the string are lost too. A string chunk in a stream given to HTMLRewriter.transform() fails the same way.

   This hits server-sent-event handlers that do controller.enqueue("data: ...\n\n") without a TextEncoder. Those worked before the flag.

   worker.js:

   export default {
     async fetch(request) {
       const body = new ReadableStream({
         start(controller) {
           controller.enqueue(new TextEncoder().encode("data: one\n\n"));
           controller.enqueue("data: two\n\n");
           controller.close();
         },
       });
       if (new URL(request.url).pathname === "/rewriter") {
         return new HTMLRewriter().transform(new Response(body));
       }
       return new Response(body, { headers: { "content-type": "text/event-stream" } });
     },
   };

   config.capnp:

   using Workerd = import "/workerd/workerd.capnp";
   
   const config :Workerd.Config = (
     services = [(name = "main", worker = .main)],
     sockets = [(name = "http", address = "127.0.0.1:8080", http = (), service = "main")],
     # typescript_implemented_streams only starts with this autogate.
     autogates = ["workerd-autogate-per-isolate-javascript-bootstrap"],
   );
   
   const main :Workerd.Worker = (
     modules = [(name = "worker", esModule = embed "worker.js")],
     compatibilityDate = "2026-02-12",
     compatibilityFlags = ["typescript_implemented_streams"],
   );

   workerd serve --experimental config.capnp
   curl -sS 127.0.0.1:8080/
   curl -sS 127.0.0.1:8080/rewriter

   With the flag (workerd 2026-10-27), both requests give:

   curl: (52) Empty reply from server
   

   with this logged:

   Uncaught exception: ... remote.jsg.TypeError: This ReadableStream did not return bytes.
   

   With compatibilityFlags = [], both requests give:

   data: one
   
   data: two
   
   

   As with the request side, rejecting strings matches the spec. But the C++ behaviour is kept for strings piped into an IdentityTransformStream (piping ledger #1: "strings are UTF-8 encoded and pass through on both"). This sink isn't in the ledgers, so I'm noting it here in case the change is unintended.
2. james-elicx commented on Oct 27, 2026

   

   james-elicx

   on Oct 27, 2026

   MemberAuthor

   More actions

   More sinks where the C++ implementation UTF-8 encoded string chunks and the flag now fails. In each case only the flag on the worker that owns the stream matters. Each one used new ReadableStream({ start(c) { c.enqueue(new TextEncoder().encode("ab")); c.enqueue("cd"); c.close(); } }):

   sink	C++	typescript_implemented_streams
   env.KV.put(key, stream)	stores "abcd"	rejects TypeError: This ReadableStream did not return bytes.
   cache.put(url, new Response(stream))	stores "abcd"	rejects with the same TypeError
   a stream passed or returned over JS RPC (with workerd-autogate-rpc-externals-hydration)	the receiver reads "abcd"	the receiver's read rejects Error: ReadableStream received over RPC disconnected prematurely.; the TypeError is only visible on the sender

   The RPC case is the most confusing one: the error the receiver sees doesn't point at the chunk type.

   Writing a string to a WritableStream received over RPC, and piping strings into an IdentityTransformStream/FixedLengthStream, still UTF-8 encode on both implementations.
3. james-elicx commented on Oct 27, 2026

   

   james-elicx

   on Oct 27, 2026

   MemberAuthor

   More actions

   The same silent loss happens with iterable request bodies (fetch_iterable_type_support, the default from 2026-02-19). Here the bytes before the string do arrive, but the string and everything after it are dropped, and fetch() still resolves:

   export default {
     async test(ctrl, env) {
       async function* body() {
         yield new TextEncoder().encode("ab");
         yield "cd";
       }
       const response = await env.UPSTREAM.fetch("http://upstream/", { method: "POST", body: body() });
       console.log(`fetch resolved ${response.status}; upstream received ${JSON.stringify(await response.text())}`);
     },
   };

   Run it with the same upstream.js and config as the issue, but with compatibilityDate = "2026-10-27".

   Without the flag:

   fetch resolved 200; upstream received "abcd"
   

   With typescript_implemented_streams:

   fetch resolved 200; upstream received "ab"
   
4. james-elicx commented on Oct 27, 2026

   

   james-elicx

   on Oct 27, 2026

   MemberAuthor

   More actions

   Two more consumers with the same root cause, a ReadableStream whose chunks are strings:

   • EventSource.from(stream) delivers no message events. The TypeError only appears as an uncaught exception, so the page just sees an empty event stream.
   • HTMLRewriter rejects This ReadableStream did not return bytes. when the strings are element.replace() content or the transformed body. Without the flag both work. The rejection is handled with .catch() but is still also logged as uncaught, which looks like HTMLRewriter reports handled source-stream errors as uncaught #7240.

   const strings = () =>
     new ReadableStream({
       start(c) {
         c.enqueue("data: hello\n\n");
         c.close();
       },
     });
   
   export default {
     async test() {
       // EventSource.from() over a stream of strings.
       const events = [];
       const es = EventSource.from(strings());
       es.onmessage = (e) => events.push(e.data);
       await new Promise((resolve) => setTimeout(resolve, 100));
       es.close();
   
       // HTMLRewriter content and input from a stream of strings.
       const page = new Response("<p>old</p>", { headers: { "content-type": "text/html" } });
       const replaced = await new HTMLRewriter()
         .on("p", { element: (el) => el.replace(strings(), { html: true }) })
         .transform(page)
         .text()
         .catch((e) => `rejected ${e}`);
       const input = await new HTMLRewriter()
         .transform(new Response(strings(), { headers: { "content-type": "text/html" } }))
         .text()
         .catch((e) => `rejected ${e}`);
   
       console.log(JSON.stringify({ events, replaced, input }));
     },
   };

   With the flag:

   {"events":[],"replaced":"rejected TypeError: This ReadableStream did not return bytes.","input":"rejected TypeError: This ReadableStream did not return bytes."}

   With compatibilityFlags = []:

   {"events":["hello"],"replaced":"data: hello\n\n","input":"data: hello\n\n"}
5. jasnell

   added 2 commits that reference this issue on Oct 28, 2026

   Encode string chunks as UTF-8 when pumping TypeScript streams

   ...

   e38d9d2

   Encode string chunks as UTF-8 when pumping TypeScript streams

   ...

   40beacd
6. jasnell

   closed this as completedin #8053on Oct 28, 2026