x/net/http2: TestTransportGroupsPendingDials failures due to missing Close

[bcmills]

--- 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)

[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.)

[gopherbot]

Change https://go.dev/cl/411294 mentions this issue: http2: enable VerboseLogs in TestTransportGroupsPendingDials

[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.

[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.