--- FAIL: TestTransportGroupsPendingDials (0.02s)
transport_test.go:401: saw 0 closes; want 1
FAIL
FAIL golang.org/x/net/http2 17.546s
greplogs -l -e 'FAIL: TestTransportGroupsPendingDials .*(?:\n[ ]{4}.*) saw 0 closes' --since=2021-01-01
2022-05-18T15:25:04-183a9ca-1f9f7db/linux-amd64-clang
2022-04-29T02:01:27-2871e0c-e7c56fe/freebsd-arm-paulzhol
2022-03-04T14:10:38-27dd868-c9b6063/freebsd-arm64-dmgk
This may be a symptom of #50027; see previously #43176.
(attn @neild @tombergan)
Comment From: bcmills
This failure mode has been observed on linux/amd64 (which is a first class port), so — especially since x/net/http2 is bundled into the standard library — this is a release-blocker for Go 1.19.
(If this isn't a priority to fix, a skip can be added to the test for this failure mode and then the issue can be moved to the backlog.)
Comment From: gopherbot
Change https://go.dev/cl/411294 mentions this issue: http2: enable VerboseLogs in TestTransportGroupsPendingDials
Comment From: neild
I'm not sure what's going on here.
This is not #50027: This test is expecting net.Conn.Close to have been called, which happens synchronously in CloseIdleConnections, not for the connection goroutines to have returned.
The only thing that makes sense is that a request has stayed live past Response.Body.Close being called (and is thus holding the connection live), which can happen in general, but I don't see how it happens in this test.
Flakes are super rare, and I haven't managed to reproduce it. Sent a CL to enable verbose HTTP/2 logging during this test; perhaps that'll point us at the problem the next time this flakes.
Comment From: neild
Removing the release-blocker label: If there's a real underlying issue, it does not need to block the release. CL 411294 will hopefully let us collect more information towards resolving the flake.
Comment From: ianlancetaylor
Rolling forward to 1.20. Please comment if you disagree. Thanks.