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
In #43176, we observed that x/net/http2.TestTransportGroupsPendingDials sometimes fails on various platforms.
The test performs multiple concurrent calls to a Transport's RoundTrip method, waits for them to return, closes the Response bodies, and then calls CloseIdleConnections. If all of those functions are synchronous — their signatures suggest that they should be, and nothing in their documentation states otherwise — then the Transport's client connection pool should be empty as soon as that sequence is complete.
However, the connection pool is empirically not empty at that point, and to my knowledge never has been. The test has had a retry loop ever since it was added (in CL 17134), and even then a single call to CloseIdleConnections before the retry loop is empirically not enough to ensure that it succeeds.
We should add more explicit tests for the expected invariants after RoundTrip and CloseIdleConnections, and/or update the documentation for those methods (and the corresponding methods and interfaces in the net/http package) to make those invariants clearer for end users, who may want to make use of any such invariants in their own tests.
CloseIdleConnections closes all idle connections synchronously.
"Closing" a connection marks the connection as closed (sets *ClientConn.closed), so it should never be used for any future requests. It also closes the connection net.Conn. However, closing a connection does not block until the connection read loop returns, and the read loop is what removes the *ClientConn from the connection pool.
So after CloseIdleConnections, some connections may be no longer in use, but still temporarily in the connection pool.
Perhaps closing a connection should block until the connection goroutines have all returned.