You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the client closed the connection and for what reason,
the server closed the connection, for example for shutdown, or
the task was cancelled, i.e. CancelledError is risen, for some other reason (distinction is probably not relevant for most applications).
It would be helpful to distinguish these cases in application code and also read the code value that was given (which would handle case 1 and case 2).
I saw that ASGI currently does not yet specify the reason value for the received disconnect (see related django/asgiref#234). I personally do not need the reason it but I noticed it to be missing in my tests.
Hacky workaround and first thoughts
Currently I hack this feature into my application by using a custom asgi_websocket_class value for my app:
Something like that, i.e. in general checking for the websocket to be closed on a CancelledError, would work for me. Modifying the scope dict is only a workaround of course. My implementation does not cover the third case above. To avoid the except+if pattern
a dedicated exception type risen on send and receive seems nice on first sight. On the other hand this will then only be risen on awaits on the websocket's send or receive whereas the cancellation strategy will stop more awaits. What one prefers is probably application dependent.
The text was updated successfully, but these errors were encountered:
Currently the
code
number of thewebsocket.disconnect
event is discarded inASGIWebsocketConnection
making it inaccessible to the application.It is currently not distinguishable whether
CancelledError
is risen, for some other reason (distinction is probably not relevant for most applications).It would be helpful to distinguish these cases in application code and also read the
code
value that was given (which would handle case 1 and case 2).I saw that ASGI currently does not yet specify the
reason
value for the received disconnect (see related django/asgiref#234). I personally do not need thereason
it but I noticed it to be missing in my tests.Hacky workaround and first thoughts
Currently I hack this feature into my application by using a custom
asgi_websocket_class
value for my app:Something like that, i.e. in general checking for the websocket to be closed on a
CancelledError
, would work for me. Modifying the scope dict is only a workaround of course. My implementation does not cover the third case above. To avoid the except+if patterna dedicated exception type risen on send and receive seems nice on first sight. On the other hand this will then only be risen on awaits on the websocket's send or receive whereas the cancellation strategy will stop more awaits. What one prefers is probably application dependent.
The text was updated successfully, but these errors were encountered: