-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WSS receive_json/string/binary API error handling #8581
Comments
Such a change sounds sensible to me atleast. Probably want errors etc. to behave similarly to .receive(). |
One of the issues with |
It is part of the public API though, and explicitly mentioned in the docs (e.g. https://docs.aiohttp.org/en/stable/client_quickstart.html#websockets). |
Maybe it makes sense to change the behaviour, but such a change would have to go into v4... |
This is in re |
Describe the solution you'd like
The current API provides for a very bizarre/absent error handling mechanism for web socket receive operations.
Specifically these are the current implementations for receiving
string
,bytes
andjson
:aiohttp/aiohttp/client_ws.py
Lines 298 to 320 in 9ed3841
As you can see any message that is not of the type
TEXT
orBINARY
will result in aTypeError
raised. However, if we inspect the underlyingreceive
, we'll see that whole bunch of error and state conditions will produce messages that are neitherTEXT
norBINARY
, includingWS_CLOSED_MESSAGE
,WSMsgType.CLOSED
andWSMsgType.ERROR
(this one is internal API implementation and should never be exposed to a user anyway) [emphasis added by****
]:So, what happens when you
receive_str
on a closed web socket? -TypeError
Server-initiated socket closing?
TypeError
TCP connection reset and disconnected?
TypeError
The
TypeError
is a builtin, its only payload is a string and information about the state or exception is entirely lost except as encoded within the error string. This is clearly not a desired API behavior.In my application internally I had to implement my own wrapper of the
receive
as follows to ensure that:None
is returned to indicateEOF
.ServerDisconnectedError
is raised.receive
, the exception is unwrapped from theWSMessage(WSMsgType.ERROR, exc, None)
and re-raised.The code is as follows and I believe the API should change along the similar lines:
Code of Conduct
The text was updated successfully, but these errors were encountered: