net/http: TestRetryIdempotentRequestsOnError flake

[bradfitz]

freebsd-amd64-race at 8adff32
https://build.golang.org/log/30e8693dc4f6f4a974cd3fe10b56a03cfc54536d

--- FAIL: TestRetryIdempotentRequestsOnError (0.28s)
	transport_test.go:2610: did not trigger any retries
FAIL
FAIL	net/http	7.277s

[vcabbage]

I can somewhat reliably reproduce this on darwin/amd64 with the -race flag.

# go test -race -c
# while ./http.test -test.run=TestRetryIdempotentRequestsOnError -test.v; do; done
=== RUN   TestRetryIdempotentRequestsOnError
finished after 34 runs
--- PASS: TestRetryIdempotentRequestsOnError (0.09s)
PASS
=== RUN   TestRetryIdempotentRequestsOnError
finished after 90 runs
--- PASS: TestRetryIdempotentRequestsOnError (0.20s)
PASS
=== RUN   TestRetryIdempotentRequestsOnError
finished after 98 runs
--- PASS: TestRetryIdempotentRequestsOnError (0.20s)
PASS
=== RUN   TestRetryIdempotentRequestsOnError
--- FAIL: TestRetryIdempotentRequestsOnError (0.21s)
	transport_test.go:2623: did not trigger any retries
FAIL

After limiting GOMAXPROCS to 1 for the duration of the test (defer runtime.GOMAXPROCS(runtime.GOMAXPROCS(1))), the test consistently triggered a retry on the first loop (ran ~100 test runs with same result).

Should I go ahead and open a CL with the change?

[bradfitz]

@vcabbage, changing GOMAXPROCS is a bit of a hack. I'd rather rewrite that whole test to be more fine-grained and thus faster and more reliable in the process.

[vcabbage]

@bradfitz Makes sense. FWIW, I ran across this when testing one of my CLs. Tripped me up because I thought I had introduced a bug.

[gopherbot]

CL https://golang.org/cl/35107 mentions this issue.