timers.go may be flaky
I ran one build, and it failed as TestBuild/ARM64Linux/timers.go, but then I ran another build and it failed as TestBuild/Host/timers.go instead. So it seems to be a bit flaky.
Running tests verbosely, I get:
=== NAME TestBuild/Host/timers.go
main_test.go:874: output did not match (expected 333 bytes, got 313 bytes):
main_test.go:875: diff expected actual
--- expected
+++ actual
@@ -4,7 +4,7 @@
waited on ticker at 500ms
- after 300ms
waited on ticker at 1000ms
-ticker was stopped (didn't send anything after 750ms)
+fail: ticker should have stopped!
waiting on timer
- after 200ms
- after 400ms
main_test.go:477: stdout: waiting on ticker
main_test.go:477: stdout: - after 150ms
main_test.go:477: stdout: - after 200ms
main_test.go:477: stdout: waited on ticker at 500ms
main_test.go:477: stdout: - after 300ms
main_test.go:477: stdout: waited on ticker at 1000ms
main_test.go:477: stdout: fail: ticker should have stopped!
main_test.go:477: stdout: waiting on timer
main_test.go:477: stdout: - after 200ms
main_test.go:477: stdout: - after 400ms
main_test.go:477: stdout: waited on timer at 750ms
main_test.go:477: stdout: timer reset: false
main_test.go:477: stdout: waiting on timer
main_test.go:477: stdout: - after 200ms
main_test.go:477: stdout: - after 400ms
main_test.go:477: stdout: waited on timer at 750ms
Yes, I've seen this issue in several other places as well. Basically, previously we used cooperative scheduling which meant that goroutines would be executed in a predictable order even when the process was delayed. But now they're running on different threads, and this makes the test essentially racy.
I'm not sure how to best fix this while making sure the original things the test was trying to test are still being tested. Perhaps increasing the timeouts helps, but that's only going to reduce the chance of hitting these issues.