In PAGI, an awaited send now fails for only one reason: a problem with your event, not with the peer [3]. Bad event shape, wrong sequence, unreadable file: the Future fails, and it fails before the connection closes [7]. A send issued after the connection has already closed stays a successful no-op that neither delivers nor raises [6]. That split is what keeps the upgrade audit narrow.
The gap those releases were closing sits between the two cases. A send Future can be pending because the server is applying backpressure, and the client can disconnect while it sits there [8]. Applications are required to await every send, so a server that left that Future pending forever would deadlock an otherwise conforming application [9]. The spec did not say whether it resolved, failed or was cancelled, nor what connection state you would observe on resumption, which meant every answer a framework invented was legal [10]. Version 0.002006 picks resolve, and pairs it with a pending receive resolving into `http.disconnect`, `websocket.disconnect` or `sse.disconnect` [11][12]. By the time your coroutine resumes from an awaited send, `is_connected()` is false and `disconnect_reason()` is set [13].
The two runtimes disagree about how to handle this, and the disagreement is worth spelling out. ASGI's spec at version 2.4 says a send on a closed connection should raise; uvicorn implemented that, broke deployed FastAPI applications, and reverted, so the dominant ASGI server contradicts its own spec, according to the PAGI writeup [15]. The reason raising looked attractive there is structural: ASGI has no out-of-band connection-state object, so raising from `send()` was the only disconnect channel it had [16]. Kestrel took the other route, silently discarding writes after a disconnect and documenting `RequestAborted` as the thing to observe, which is the role `pagi.connection` plays [17]. TCP settles the argument for me. Writes to a dead peer succeed into kernel buffers for a while whatever your API promised, so a contract of "sends fail when the client is gone" promises something the network will not deliver [18].
Eight releases over five days is 1.6 a day [20], and the whole of it reaches a normal request/response application as two sentences [5]. That ratio reflects specification work rather than feature work. Worth noting where my copy runs out: the guarantee list is followed by a sentence beginning "Servers that implement all of t", and the supplied text stops there [21], so I cannot tell you what conformance claim the post goes on to make.
The provenance is the part I find most persuasive. The clauses came out of a streaming response helper, which grew a flag for a disconnect arriving while inside a send call, then a flag to defer publishing the disconnect until the send settled, and was heading toward a custom Future subclass that tracked whether a failure had been observed yet [19]. A Future subclass that keeps notes on whether anyone has noticed its failure is a sign the spec needs re-reading. The author states it directly: when the fixes start needing philosophy, something upstream is wrong [22].
