net: TestListenerClose failures with "Dial to closed TCP listener succeeded"

[bcmills]

2020-04-27T15:50:54-70d9b72/linux-386-longtest

--- FAIL: TestListenerClose (0.00s)
    --- FAIL: TestListenerClose/tcp (0.00s)
        net_test.go:277: Dial to closed TCP listener succeeded.
FAIL
FAIL	net	29.631s

See previously #14124.

CC @mikioh @bradfitz @ianlancetaylor

[bcmills]

greplogs --dashboard -md -l -e 'FAIL: TestListenerClose' --since=2020-04-28

2021-09-02T16:59:57-2a463a2/linux-amd64-longtest
2021-08-18T15:11:52-0c83e01/linux-s390x-ibm
2021-08-16T18:52:20-d35035f/linux-386-longtest
2021-05-05T01:48:39-caf4c94/openbsd-386-68
2021-04-30T16:17:01-cc02d59/linux-s390x-ibm
2020-12-29T20:35:10-b4a71c9/plan9-amd64-9front
2020-10-19T18:25:30-bb44c90/linux-386-longtest
2020-10-16T16:52:13-dfee333/linux-386-longtest
2020-10-01T21:06:35-507a88c/linux-386-longtest

[bcmills]

greplogs --dashboard -md -l -e 'FAIL: TestListenerClose' --since=2021-09-03

2021-11-11T04:54:05-4b27d40/dragonfly-amd64
2021-11-04T02:38:03-747e4af/linux-amd64-longtest
2021-11-02T20:47:30-b246873/linux-386-longtest

[bcmills]

greplogs --dashboard -md -l -e 'FAIL: TestListenerClose.*\n(?: .*\n)*.*Dial to closed TCP listener succeeded' --since=2021-11-12

2021-12-09T19:01:08-8ff254e/linux-amd64-staticlockranking

[bcmills]

This test is failing with some regularity on builders for first-class ports (notably linux-386 and linux-amd64). To my mind, that makes it a release-blocker via #11811.

Either we should fix the net package to satisfy the expectations of the test, or we should fix the test to match the realities of the net package. (If nothing else, the failing check could be removed from the test without rendering it useless.)

[bcmills]

Notably, this assertion begins with a time.Sleep for an arbitrary duration, and then asserts that a Dial call does not succeed:

go/src/net/net_test.go

Lines 273 to 279 in f229e70

	time.Sleep(time.Millisecond)
	cc, err := Dial("tcp", dst)
	if err == nil {
	t.Error("Dial to closed TCP listener succeeded.")
	cc.Close()
	}

If I understand correctly, the test does not (and cannot feasibly) ensure that the port is not simultaneously reused by some other test — or even some entirely different process! — on the system, since the TCP TIME_WAIT state only strictly applies to the four-tuple of (source address, source port, destination address, destination port). net.Dial specifies only the destination address and port, so a new listener may immediately be opened on the same address and port as long as it only accepts connections from new source addresses and/or ports. Thus, the Dial may spuriously succeed by connecting to an entirely new listener at the same port.

[bcmills]

I'll send a CL to remove the erroneous assertion.