Open jogc opened 1 day ago
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
aiohttp Version
multidict Version
propcache Version
yarl Version
OS
Raspbian GNU/Linux
Related component
Client
Additional context
No response
Code of Conduct