This PR suggests an alternative: to keep running the test until success, subject to a generous timeout, rather than guessing delays and coarsely trade-offing false negatives against test duration.
I've converted only the offending test to validate the approach, but AFAICT the other tests would also benefit.
https://github.com/obsidiansystems/rhyolite/issues/200 turned out to be caused by the test not being yet finished in time. Duplicating the delay here https://github.com/obsidiansystems/rhyolite/blob/151649c516061dc766d46b526aba068274f7e0e6/beam/task/backend/test/Test.hs#L254 consistently yield test success for me. FWIW, I'm running Ryzen 1800X, meaning 8 cores 16 threads. I suspect this test might need even more time on machines with less cores, unless it's IO bound? Another downside is this makes the test duration increase from around 26s to around 34s on my machine.
This PR suggests an alternative: to keep running the test until success, subject to a generous timeout, rather than guessing delays and coarsely trade-offing false negatives against test duration. I've converted only the offending test to validate the approach, but AFAICT the other tests would also benefit.