internal/singleflight: test flake

[bradfitz]

https://storage.googleapis.com/go-build-log/2d6a1955/windows-amd64-gce_21f24cce.log

...
--- FAIL: TestDoDupSuppress (0.01s)
    singleflight_test.go:74: number of calls = 10; want over 0 and less than n
FAIL
FAIL    internal/singleflight   0.076s
...

[rsc]

Why should it be less than n?

[bradfitz]

The error message is trying to say that at least one of n calls should be dup-suppressed.

I can imagine various test-deflaking strategies but I wanted to reproduce it before I mailed one out. So far I've been unable to reproduce on Darwin or Linux, so I'll try Windows next.

[aclements]

I've been running run.bash in a loop on my linux/amd64 workstation for the past few days and I've gotten this failure at least once. I think Rick has run in to it, too.

This test seems broken to me. If the goroutines started in the loop run sequentially, calls will be 10. I'm not sure we can fix this without relying on timing in some way, but what if instead of the outer goroutine doing the delay, the first call to fn sent to the channel and then slept for a bit? That would ensure at least one of them was in the Do and that duplicate suppression was active for the duration of the sleep.

[aclements]

I can reproduce this pretty easily on my linux/amd64 laptop with

stress -p 16 ./singleflight.test -test.short

where 16 is four times the number of CPUs on the machine. The overload seems to be necessary.