Learned a new QUIC API trick from a coworker yesterday.
It's a way to make sure connections close gracefully in a particular protocol pattern (because of course it's about graceful close).
The case we're looking at are clients that want to do a bunch of requests that upload data (no HTTP3 btw).
Jan 22, 2026 08:58Usually, you'd apply the rule of "the last one to receive closes the connection".
Because otherwise you might interrupt an in-progress send!
However, in this case the server is the last one to receive data, and it doesn't really know if the client wants to do another "upload" in the same connection.
The easy answer is for the server to send back a message "ok, done receiving", and when the client has picked that up for all of its desired uploads, it can close the connection.
This is effectively what would happen if you implemented such a protocol on top of HTTP3.
If you're doing this on top of a native QUIC API though, there is a small trick.
There are some "native" messages/notifications that you can send in QUIC. The "FIN" message at the end of a stream is one such example. Besides being a notification for end-of-stream, you could use it for anything.
So in this case, the client could wait for the server to send it after the upload finishes:
Essentially, we can skip sending a message on the response stream, because the "FIN" that's sent is already one such message. So `received_reset().await` is enough (which waits for a FIN or reset to be sent).
0 "actual" stream bytes sent.
For completeness' sake, here's the receiving side:
I wrote a lot more about QUIC stuff on one of our docs pages, but this trick was new to me, and I didn't cover it in there yet, so on bsky it goes until I get to updating that!
docs.iroh.computer/protocols/us...
