* updates dependencies

* adds a tsconfig to fix type error
ExecutionContext was missing in worker.ts.  it's actually unused, but I was thinking that it was probably here (since this is an example) to show it, so instead of deleting it to remove the type error I fixed the problem by adding a tsconfig referencing the types which are present in the root.  if it'd be better to give this example  its own package.json to install the cloudflare worker types, I'm happy to update! lemme know

* prevent layout thrashing with callbacks
This prevents unnecessary function recreations on every render, which is especially important since runDemo is passed to the button's onClick handler.

* prevent falsey react rendering
conditional rendering using && can cause issues in React because when left side is falsy, it renders that falsy value (like false, null, 0). although code like this used to be common, people use ternaries with explicit null these days, considering it safer.

* some basic styling
I tried to keep it as non-invasive as possible, but in order to make the chart responsive I switched from SVG to plain divs (that will become important in the next commit where I will scale both)

* comparison bar
in the summary, it would be nice to have a side-by-side horizontal histogram

* spell out initialism

---------

Co-authored-by: dimitropoulos <dmitropoulos@cloudflare.com>

Use key remapping to filter out symbol keys instead of mapping to never.
Fixes Disposable compatibility issue with RPC types.

Ref: cloudflare/workerd#5804

* Update dependencies.

* Test proxying an RPC stub all the way to Durable Objects.

In particular, the DO keeps a dup() of the stub and uses it later, after the original subscription call has returned. This requires the `rpc_params_dup_stubs` compat flag, which became default as of 2026-01-20, hence the compat flag update.

Fixes #110.

…ith automatic flow control. (#132)

* Refactor: RpcPayload.stubs -> hooks

Instead of storing an array of RpcStub, we now store an array of the underlying StubHooks.

This will make it easier to add support for new types like streams, which aren't RpcStubs, but they will wrap / be wrapped in StubHooks.

* Add support for sending WritableStream over RPC.

(Flow control is left for a future commit.)

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/gJU0pT8p

(I cleaned some stuff up manually.)

* Add support for sending a ReadableStream over RPC.

As described in protocol.md, the basic idea here is that whenever we want to send a ReadableStream, we first send a message to the other side creating a "pipe". We pump our ReadableStream to the pipe's WritableSteam end, and we deliver the pipe's ReadableStream end to the remote peer. This way, we can begin pushing bytes immediately upon sending a ReadableStream, without waiting for the remote end to call back asking for the bytes (which would be an unnecessary round trip).

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/ctbbBnOu

* Implement backpressure for streams.

If more than 256kb of writes are in flight, we pause writes until past writes complete so that the number drops back below 256kb.

Future commits will expand the window size.

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/D1bqkx2K

This was not the best Claude session. I could probably have done it faster by hand.

* Optimization: Elide "pull" and "resolve" for streaming calls.

We add a new "stream" message to the protocol which skips these. See protocol.md for explanation.

(Since this is only used for streams, which were just introduced in this PR, this is not a breaking change.)

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/OfY838e7

* Add changeset for streaming.

* Adaptively resize streaming windows.

With this change, we'll automatically update a stream's window size based on the observed bandwidth-delay product, in order to fully saturate the stream with minimal additional buffer bloat.

The algorithm works by observing when each stream chunk is sent and acknowledged (via return from the RPC), allowing us to calculate:
1. Minimum round trip time.
2. Running average bandwidth over the last RTT.

From that we calculate bandwidth-delay product and adjust the window to match. We actually set the window a bit bigger than the calculated BDP during startup (2x) and steady-state (1.25x) so that we can observe if the actual bandwidth is greater than expected, and thus update the window accordingly.

I worked with Claude+Opencode to design the algorithm and implement, although I significantly refactored almost everything it wrote as the code was pretty meh: https://share.opencode.cloudflare.dev/share/rGV0SKLW

* Document streaming support in readme.

* Fix streaming error propagation.

This bug was caught and fixed by AI (prompted by @dmmulroy): #132 (comment)

This commit applies exactly the suggestion from the comment.

* Fix occasional hang in stream tests.

This was a pain to track down, when the code goes into a busy loop, vitest gets very confused. It fails to display console.log()s that happened before the hang and doesn't even correctly report which test is running -- often claiming it's still working on some previous test. Ugh!

Anyway, it turns out that the stream implementations on some platforms require macro tasks to make progress, so pumping only microtasks doesn't get there. Weirdly, it seems to be non-deterministic. I was seeing workerd hang maybe 1/4 of the time, and webkit also hang sometimes but less often. It's possible the other platforms were also affected but even more rarely and I just never saw it happen.

* Fix ReadableStreams in received payloads not being disposed.

Fix and test provided by @dmmulroy here: #132 (comment)

* Don't cancel ReadableStreams that are locked.

I noticed that the `state.stream.cancel()` call in `ReadableStreamStubHook.dispose()` was often failing, throwing an exception because the stream was already locked. But we were ignoring the exceptions.

This actually fixes the problem in two ways:
1. When we pipe from a ReadableStream (which locks it), we also take a reference on its StubHook, which we dispose then the pipe completes. This makes sense and solves the case seen in the tests.
2. I also just made it skip the cancel() call if the stream is locked. Throwing the exception and ignoring it is just a waste of cycles.