Change:
} } <ins> function makeDelayedText(Model) { let error, _resolve, _reject; let promise = new Promise((resolve, reject) => { _resolve = () => { promise = null; resolve(); }; _reject = e => { error = e; promise = null; reject(e); }; }); function DelayedText({children}, data) { if (promise) { throw promise; } if (error) { throw error; } return <Model>{children}</Model>; } return [DelayedText, _resolve, _reject]; } </ins> it('should resolve HTML using W3C streams', async () => { function Text({children}) { return <span>{children}</span>;

Discussion:
When using for e.g. Cloudflare Workers runtimes, I'm noticing this error on the server: I'm assuming this results in the following malformed chunk being sent to the stream: Which results in the client failing: I put together a reproduction here, powered by for the Workers runtime: Could this be related to the "fundamentally flawed" nature of Web Streams implementations in e.g. Cloudflare Workers runtime? Is something going on with corking/uncorking, as per Maybe something's wrong with Miniflare's polyfill and this is a non-issue, coming from ? Finally, it's possible something is wrong with the Vite version of the example I've put together. I could try rebuilding with webpack if it's determined none of these items apply.
Have you looked at what chain of assumptions leads to this? It seems like it would be good to understand what different state machines are involved and why something's happening in CF that doesn't happen in the browser.
Have you looked at what chain of assumptions leads to this? after lots of digging, here's what we've discovered: The difference between Cloudflare/Oxygen Workers runtimes and the browser comes down to how the is consumed after being passed to . In the browser and , this is how the stream (via ) is consumed: This presumably results in a single . In the worker runtime, is read through an : Importantly, this results in getting called multiple times as more data is enqueued and as the reader sees fit. This is an assumption on my part, so I could be wrong here. When combined with Suspense boundaries, callbacks trigger . At the same time, repeated requests from the stream reader also call . This results in the following error on the server: You can also reproduce this directly in the browser by attempting to read the stream with . Here is a new fixture with a reproduction of the issue, including a couple test cases that show the different errors you'll see based on the number of Suspense boundaries you have: If this seems like a legitimate bug to you, a couple ideas I had: Should there be some sort of check like in ? Should we splice completed boundaries earlier to account for concurrency so they are removed from the array and not re-flushed? Here are some other resources and scratch notes:
~We'll fix this reentrancy bug somehow.

However, right now it's a bit lower priority because CloudFlare technically don't support ReadableStreams and so you have to go through the polyfill and any subtle differences might be due to the polyfill. To really know if we fixed this issue we should apply this to native CloudFlare ReadableStreams... which I'm told is coming. So that's how we know if it actually worked. Until then, the support for CloudFlare workers is... partial.~ On a second thought this should probably fix it. I think I finally understand how it's supposed to work now.
Please take another look and see if this fixes all the issues you've noticed.
works like a charm! Thanks for taking the time to look at it and get it fixed