-
-
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: _pong_not_received
works (mostly) correctly but outcome is erased by receive
's except EofStream:
#8540
Labels
Comments
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 27, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 28, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 28, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
5 tasks
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 29, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
5 tasks
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 29, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 29, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
arcivanov
added a commit
to arcivanov/aiohttp
that referenced
this issue
Jul 29, 2024
Make sure to unblock the `receive` operation by feeding the receiver an error in a `WSMessage` Change `TimeoutError` to `ServerTimeoutError` to accurately represent failure (this is backwards compatible since `ServerTimeoutError` has `TimeoutError` in the MRO) fixes aio-libs#8540
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I'm testing a condition where a network connection is severed to see how application behaves and recovers. This is accomplished by switching the laptop into an airplane mode, disabling the WiFi interface, i.e. a hard disconnect.
I noticed that application shuts down as if receiving a normal exit signal, which isn't supposed to happen.
Tracked this down to the following:
When connection is severed with my activated
heartbeat
of 5.0,_pong_not_received
works mostly correctly:aiohttp/aiohttp/client_ws.py
Lines 116 to 121 in e057906
However, the concurrent
receive
that returns some time thereafter withEofStream
erases all information about the abnormal shutdown:aiohttp/aiohttp/client_ws.py
Lines 253 to 256 in e057906
Additionally, and corollary to the above, the way
_pong_not_received
closes the connection does not unblock thereceive
at all, becauseself._close
is set as opposed to callingself.close()
, which would then feedreceive
termination data immediately. That doesn't happen and whenreceive
finally receives theEofStream
, it's oblivious as to the cause.I'm working on a patch.
To Reproduce
WSCloseCode.OK
waaaay past the heartbeat timeout with no indication anything went wrong.Expected behavior
receive
:_pong_not_received
whenEofStream
is received._pong_not_received
with proper termination cause._pong_not_received
should probably useself.close()
Logs/tracebacks
Python Version
aiohttp Version
multidict Version
yarl Version
OS
Fedora 40, Linux, x86_64
Related component
Client
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: