Cancel blocked server-stream handlers on client disconnect

[stefanvanburen]

#175 made the server watch receive() for http.disconnect during server streams, but the response loop only checks for it between messages, so a handler that's waiting to produce its next message (a health Watch that only yields on status changes, say) keeps running until it next yields or hits its deadline. This runs the response loop inside an asyncio.timeout(None) scope that the watcher reschedules to now on disconnect, which cancels whatever the loop is awaiting, the handler's anext or a send, and ends the call as CANCELED as before. The handler's and stream interceptors' finally blocks run and on_end sees CANCELED.

Bidi and client streams have the same gap once the request body ends, but there the handler is the one reading receive(), so a separate watcher would steal body chunks. Covering them needs a single task that owns receive() for the whole call, which I'd rather do as a follow-up, especially since #348 rewrites this code for trio. This maps onto its watch_for_disconnect; under trio the scope would be a CancelScope.

[anuraaga]

Makes sense and the context manager seems much cleaner. But wondering if we need to merge this before #348 and #383

PS: I could finally get it from reading the code but Claude descriptions are ungrokkable to me now adays ;)

[stefanvanburen]

PS: I could finally get it from reading the code but Claude descriptions are ungrokkable to me now adays ;)

agreed; this one was particularly dense. although tbh, the code itself is really quite subtle, at least to me. :)

But wondering if we need to merge this before #348 and #383

do you mean you'd like to land those first? Happy to hold off until we get those situated given that these are all in roughly the same area of the codebase!