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

This stack of pull requests is managed byGraphite. Learn more aboutstacking.

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

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

@spikecurtis I've gone with an approach similar to that used bydbpurge_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 userequire.Eventually.

EDIT: An unrelated test is failing because it callsclock.Set with a time after the nextmetricscache tick time (which quartz does not allow).
If we want to go with this solution, we may need to stop piping the clock fromcoderdtest.Options through tometricscache, and just always give it a real clock when created as part of acoderdtest.
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 testbefore 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=1ok      github.com/coder/coder/v2/coderd/metricscache   5.099s~/coder [ethan/deployment-stats-flake] » go test github.com/coder/coder/v2/coderd/metricscache -count=1ok      github.com/coder/coder/v2/coderd/metricscache   0.118s

🎉