It's something very complicated to reproduce, it seems that the condition is very specific, perhaps you have more experience with the lib to find a common point for correction.
So far my guess is that this issue is related to the asynchronous closing of connections. According to the discussion in the issue golang/go#50027:
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.
Would it be possible to adjust the implementation in go-retryablehttp to ensure that all connection goroutines are finished before removing the connection from the pool? This would help prevent panics like the one mentioned above.
Versions:
Description: I encountered a panic related to HTTP/2 connections while using the
go-retryablehttp
library. The panic message is as follows:It's something very complicated to reproduce, it seems that the condition is very specific, perhaps you have more experience with the lib to find a common point for correction.
So far my guess is that this issue is related to the asynchronous closing of connections. According to the discussion in the issue golang/go#50027:
Would it be possible to adjust the implementation in
go-retryablehttp
to ensure that all connection goroutines are finished before removing the connection from the pool? This would help prevent panics like the one mentioned above.Thank you!
More related issues :