NO-JIRA: [Python] IO: Add ENETUNREACH to the list of tolerated errors #365
Conversation
...which will enable reconnection logic to act in this case. ENETUNREACH can happen when target network is unreachable for example when the network stack was not fully initialized yet or when a network is not connected temporarily, etc. This makes ENETUNREACH handled just like EHOSTUNREACH (which is for some reason indicated with EINPROGRESS in this part of the code). Signed-off-by: Ievgen Popovych <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #365 +/- ##
===========================================
+ Coverage 68.24% 88.36% +20.11%
===========================================
Files 367 47 -320
Lines 73285 2397 -70888
===========================================
- Hits 50011 2118 -47893
+ Misses 23274 279 -22995 Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Thanks for looking at and debugging the issue you found. I'm pretty sure this isn't the correct place for the fix (even if it was the easiest place to fix your issue).
In future it really helps us to raise an issue connected with fixes for tracking purposes also to understand the environment of the issue - was this under Windows/MacOS or Linux for example as the errno behaviour can vary between the platforms.
Certainly your comment about EHOSTUNREACH is not true for Linux, and that seems to me to be a much more important connect failure case than ENETUNREACH.
| @@ -65,7 +65,7 @@ def connect(addr) -> socket.socket: | |||
| try: | |||
| s.connect(addr[4]) | |||
| except socket.error as e: | |||
| if e.errno not in (errno.EINPROGRESS, errno.EWOULDBLOCK, errno.EAGAIN): | |||
| if e.errno not in (errno.EINPROGRESS, errno.EWOULDBLOCK, errno.EAGAIN, errno.ENETUNREACH): | |||
There was a problem hiding this comment.
I'm pretty sure this change doesn't make sense at this point in the code:
The very low level connect is only making sure that a connect on a nonblocking socket worked - the only "non errors" on a non blocking socket are the ones listed - they indicate that the operation is in progress.
ENETUNREACH indicates that the connect operation failed (at this low level). Any retries because of this kind of failure need to be handled at a higher level.
Sure, thanks for the feedback! Should I open an issue (at this point)? |
I think this deserves an issue - although there may already be an issue about reconnect not correctly working if the failure is the initial connect operation.
It could well be that in the case of EHOSTUNREACH this doesn't get discovered immediately which makes it EINPROGRESS, but eventually fails when the target router sends back the unreachable ICMP packet. |
|
Opened PROTON-2528. |
...which will enable reconnection logic to act in this case.
ENETUNREACHcan happen when target network is unreachable for examplewhen the network stack was not fully initialized yet or when a network
is not connected temporarily, etc.
This makes
ENETUNREACHhandled just likeEHOSTUNREACH(which is for some reason indicated with
EINPROGRESSin this part of the code).