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
A raw Python built-in TimeoutError / socket.timeout is let through in rare cases instead of an aiohttp.ClientError being generated. I would expect it being enough to handle aiohttp.ClientError to write robust code. It happens when socket.recv raises TimeoutError (or socket.timeout in older Python versions) due to recv syscall returning ETIMEDOUT. I'm not able to reproduce it but what I think happened in my case was that the connection was successfully established and right after the machine lost internet connectivity before/during the HTTP request headers being sent which causes Linux to timeout waiting for TCP ACK for the sent data.
This occurred on Python 3.7.3 / aiohttp 3.7.4.post0 but it seems aiohttp 3.8.5 on Python 3.11.2 also doesn't handle TimeoutError. I am not able to test on the latest version(s) sorry.
To Reproduce
Modify /usr/lib/python3.7/asyncio/selector_events.py by inserting a raise TimeoutError before every instance of recv being called.
Expected behavior
I expected an aiohttp.ClientOSError to be raised and since I handle aiohttp.ClientError that would have been enough.
Logs/tracebacks
python3[4494]: ERROR:asyncio:Fatal read error on socket transportpython3[4494]: protocol: <RequestHandler connected>python3[4494]: transport: <_SelectorSocketTransport fd=10 read=polling write=<idle, bufsize=0>>python3[4494]: Traceback (most recent call last):python3[4494]: File "/usr/lib/python3.7/asyncio/selector_events.py", line 801, in _read_ready__data_receivedpython3[4494]: data = self._sock.recv(self.max_size)python3[4494]: TimeoutError: [Errno 110] Connection timed out
Python Version
3.7.3
aiohttp Version
3.7.4.post0
multidict Version
5.1.0
propcache Version
WARNING: Package(s) not found: propcache
yarl Version
1.6.3
OS
Raspbian GNU/Linux
Related component
Client
Additional context
No response
Code of Conduct
I agree to follow the aio-libs Code of Conduct
The text was updated successfully, but these errors were encountered:
We're not about to provide updates or try to figure out what is happening from 3 major versions ago. The description is fairly vague, but there's a good chance the issue no longer exists in 3.11. You'll need to test against the current version.
Describe the bug
A raw Python built-in TimeoutError / socket.timeout is let through in rare cases instead of an aiohttp.ClientError being generated. I would expect it being enough to handle aiohttp.ClientError to write robust code. It happens when socket.recv raises TimeoutError (or socket.timeout in older Python versions) due to recv syscall returning ETIMEDOUT. I'm not able to reproduce it but what I think happened in my case was that the connection was successfully established and right after the machine lost internet connectivity before/during the HTTP request headers being sent which causes Linux to timeout waiting for TCP ACK for the sent data.
This occurred on Python 3.7.3 / aiohttp 3.7.4.post0 but it seems aiohttp 3.8.5 on Python 3.11.2 also doesn't handle TimeoutError. I am not able to test on the latest version(s) sorry.
To Reproduce
Modify /usr/lib/python3.7/asyncio/selector_events.py by inserting a
raise TimeoutError
before every instance ofrecv
being called.Expected behavior
I expected an aiohttp.ClientOSError to be raised and since I handle aiohttp.ClientError that would have been enough.
Logs/tracebacks
Python Version
3.7.3
aiohttp Version
3.7.4.post0
multidict Version
5.1.0
propcache Version
WARNING: Package(s) not found: propcache
yarl Version
1.6.3
OS
Raspbian GNU/Linux
Related component
Client
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: