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 connection to #57475 doesn't seem likely to me. That test uses test hooks to force a timeout, and those failures were about a forced timeout not happening as fast as expected. This test is not using test hooks and appears to be making real network connections.
This made me think of #37795, although the setup is a bit different and I don't think that precise bug should apply here.
I ran the test case from #37795 (comment) to see if the underlying macOS bug causing #37795 still exists. This test consists of a C client and server. The client loops, connecting to the server and immediately closing each connection. The server accepts connections, attempts to read one byte (returning EOF), and then closes the connection. Previously, this test would hang in the read.
The read timeout seems to be fixed, but the client in this test now hangs for me after a few iterations, returning ETIMEDOUT from connect. That seems like the same behavior seen in the flake here.
Not sure yet if this is a kernel bug or something else (port exhaustion? antivirus getting out of hand?).
Run the server. Run the client. The client makes connections to the server and closes them, with a delay every 100 connections to avoid ephemeral port exhaustion. After a while (seems to take ~16,000 connection attempts for me, so 2-3 minutes) the client's connect call fails with ETIMEDOUT.
I ran this on my Google-issued laptop and got the failure, but I've been unable to reproduce it on my personal MacBook Pro. It's possible this one is due to some non-standard antivirus or firewall on the Google laptop.