• test: fix TestCache_DeploymentStats flake #19683 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Can we stop using Eventually entirely? Like, make this test actually deterministic?

Can we stop using Eventually entirely? Like, make this test actually deterministic?

@spikecurtis I've gone with an approach similar to that used by dbpurge_test, though I had to change the way the ticking works slightly. This seems preferable to modifying the API of the metrics cache.

If this approach looks good to you, I'll update the other tests to also no longer use require.Eventually.

EDIT: An unrelated test is failing because it calls clock.Set with a time after the next metricscache tick time (which quartz does not allow).
If we want to go with this solution, we may need to stop piping the clock from coderdtest.Options through to metricscache, and just always give it a real clock when created as part of a coderdtest.
Alternatively, those tests that need to set the clock to a time in the future could just choose really long tick intervals.
WDYT?

In general, clock.Set is discouraged other than start of test before you pass it to anything.

Also, Quartz mocks are not really designed for integration tests where you have a whole lot of things calling into the clock with different intervals.

~/coder [main] » go test github.com/coder/coder/v2/coderd/metricscache -count=1
ok      github.com/coder/coder/v2/coderd/metricscache   5.099s

~/coder [ethan/deployment-stats-flake] » go test github.com/coder/coder/v2/coderd/metricscache -count=1
ok      github.com/coder/coder/v2/coderd/metricscache   0.118s

🎉