PAGI 0.002006: Spec Update Fixes Streaming and Disconnects
Explore PAGI 0.002006 and 0.002007 releases addressing connection contracts, streaming edge cases, and simplifying app code.

Stock photo for illustration only, not from the actual event
- PAGI rolled out four spec releases and four server releases in five days to fix disconnect handling.
- Normal apps upgrade with a simple two-sentence rule: sends can fail if malformed, and always finish responses.
- Streaming issues occurred because the old spec never defined what happens when clients disconnect during a pending send.
- The new spec adopts a .NET Kestrel-style approach using pagi.connection instead of throwing immediate errors.
If you have been watching the PAGI changelogs this month, you will have noticed a burst of releases featuring four spec releases and four server releases in five days, accompanied by titles full of terms like settlement, transition order, and RST_STREAM. This post explains what that churn actually was, why almost none of it requires application changes, and why the small part that does touches applications to make them simpler rather than more complicated.
For a normal request/response application, your entire upgrade note consists of two sentences: awaited sends can now fail if your events are malformed or out of sequence from being silently ignored previously, and always finish your responses since an incomplete response is now loudly abnormal instead of a silent hang. Everything else in this post guarantees features you inherit without writing a single line of code.
The trigger was framework work rather than server work. While building a streaming response helper on top of PAGI, the team hit a classic async rabbit hole where every fix for a disconnect race exposed another one. The helper grew flags to track whether a disconnect arrived during a send call and to defer publishing until the send settled.
The root cause was the spec itself. PAGI was always precise about certain disconnect cases, but said nothing about the scenario streaming apps live in: a send Future already pending while the server applied backpressure when a client disconnected. Nothing specified whether it resolves, fails, or gets cancelled, leaving frameworks to invent legal answers that ultimately failed to work.

Stock photo for illustration only, not from the actual event
Managing disconnect handling in asynchronous web frameworks remains one of the trickiest engineering challenges because networks do not instantly signal dropped peers. Establishing a clear contract between servers and applications helps developers avoid writing repetitive, ad-hoc workaround logic.
Before writing new clauses, the developers examined how other ecosystems answered this. ASGI went the other way by specifying that a send on a closed connection should raise an error. Uvicorn implemented it, which broke deployed FastAPI applications and forced a reversion. On the other hand, .NET's Kestrel provided a stable precedent where writes are silently discarded and applications observe a RequestAborted cancellation token, which serves as the exact moral equivalent of PAGI's pagi.connection object.
Consequently, PAGI 0.002006 completes its existing doctrine instead of reversing it. The new contract allows large streaming downloads to stop working the moment a client departs without wrapping every send in exception handling.
"Awaited sends can now fail if your events are malformed or out of sequence and always finish your responses."
PAGI Changelog
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment