Very odd that this would have suddenly occurred on three different platforms. Assuming that the original bug was not recurred, this is basically testing how long it takes to start a new goroutine. Very hard to believe that it would take half a second when nothing else should be going on.

CC @mknyszek @prattmic

greplogs --dashboard -md -l -e 'FAIL: TestParallelSleep' --since=2021-04-16

2021-11-04T07:05:31-2622235/windows-amd64-2012
2021-08-26T17:18:58-d6bdae3/windows-amd64-noregabi
2021-08-20T03:25:17-c92c2c9/windows-amd64-2016
2021-05-27T19:55:46-cdcd028/openbsd-arm64-jsing

One more today. This test failure seems potentially relevant to #44343, too.

greplogs --dashboard -md -l -e 'FAIL: TestParallelSleep' --since=2021-11-05

2022-01-27T21:11:21-f5fe5a4/windows-amd64-2016

greplogs --dashboard -md -l -e 'FAIL: TestParallelSleep' --since=2022-01-29

2022-03-09T21:31:58-a987aaf/windows-amd64-2016

Marking as release-blocker for Go 1.19.

(If this isn't a priority to fix for 1.19, we should skip the test so that it doesn't continue to add noise to the builders.)

For reference, this test was added for issue #1560. It starts two parallel 1 second sleeps and checks that they overlap by at least 500 ms.

I'm not surprised this is flaky because it's fundamentally sensitive to timing and scheduling. It also takes a second to run.

I'm inclined to just delete this test. I think it's doing more harm than good.

I'll replace with a test for the same problem that is not timing dependent.

Change https://go.dev/cl/400194 mentions this issue: misc/cgo/test: remove timing dependency from TestParallelSleep