I think this part would be blocked until the write confirmation comes back. Cloudflare can presumably achieve this in the network stack, so it should be agnostic to the code/library/platform.
Those APIs (i.e. fetch) are regular async/promise based. And in this synthetic scenario you can't construct your response-to-caller without something in that respond payload. I don't see a way to solve this all with magic.
This all strikes me as very similar to promise pipelining and distributed capabilities from an OCap system like E.
Any code sending an outbound request in reaction to a write is causally related and could be represented as a pipelined promise. The receiving system can then proceed in its work until it needs to "await" the incoming promise and can see whether it was broken due to a failure to persist some earlier write. This could also be handled at the network layer if the receiving system was external.
I'm pretty sure I remember Kenton announcing that Cloudflare Workers now supports something like (or exactly) object capabilities and promise pipelining and his knowledge/interest in such systems is already reflected in Cap'n Proto RPC.
At present output gates operate on the scope of a single worker, blocking the output from being sent. It's easy to imagine, though, that we extend things so if you are sending a message to another worker (including a Durable Object), the message is sent immediately, but the destination worker becomes subject to the same output gate. Haven't done it yet but would definitely like to!
I think this part would be blocked until the write confirmation comes back. Cloudflare can presumably achieve this in the network stack, so it should be agnostic to the code/library/platform.