Franz Busch

> Is there any reason this shouldn't use the existing close ratchet functionality we have to default to half-closure? We already know the closure state of the system, and half-closure...

Right, different proposal then. What if we make `writer.finish()` async? And we attach a promise to the `close(mode: .output)`. That should give us the guarantee back that the writes made...

I think we have two orthogonal but related points here. 1. `executeThenClose` is currently prone to dropping writes. We should try to ratchet this down by doing half closure 2....

> Sure, but a HTTP response shouldn't be just one write. The body has to be streamed, and so it's _n_ writes. Yes, for users who write their programs carefully...

> Currently, the proxy use case will anyway be slow because of the thread hops which also cost ~3 orders of magnitude more than that single promise. The thread hops...

> So maybe a more radical redesign is worth considering. How about we remove `.write` altogether, and _only_ offer a `batch` style write API. Essentially, force all users to issue...

> Do we? We already have intermediate storage in the async writer. I think it is very possible to produce an implementation of this API that does not require temporary...

Thanks for opening this. The problem is similar to what we see in H2 when the consuming task of the inbound streams sequence gets cancelled. Currently both async sequences in...

We have intentionally not adopted caching yet since it trades potential time saving for cost. I am going to kick-off the CI here since I want to see what the...

@MahdiBM Can we make re-runs work. Then I can trigger the CI again to see the impact