[BUG] flytestdlib/cache unit tests are flaky

[Sovietaced]

Describe the bug

During a recent build in CI I encountered a unit test failure. I noticed that pluggable / test time sources aren't being used in thees unit tests which may lead to flakes depending on how slowly the unit tests are executed. It would be best to use a test time source instead, it will also speed up the tests because they won't have to sleep.

--- FAIL: TestCacheFour (8.11s)
    --- FAIL: TestCacheFour/Test_panic_on_sync_and_shutdown (5.50s)
        auto_refresh_test.go:200: 
            	Error Trace:	/home/runner/work/flyte/flyte/flytestdlib/cache/auto_refresh_test.go:200
            	Error:      	Condition never satisfied
            	Test:       	TestCacheFour/Test_panic_on_sync_and_shutdown
        auto_refresh_test.go:208: 
            	Error Trace:	/home/runner/work/flyte/flyte/flytestdlib/cache/auto_refresh_test.go:208
            	Error:      	Not equal: 
            	            	expected: 10
            	            	actual  : 0
            	Test:       	TestCacheFour/Test_panic_on_sync_and_shutdown

Expected behavior

The unit tests pass and are deterministic.

Additional context to reproduce

No response

Screenshots

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[runllm]

The issue you're experiencing with flaky unit tests in flytestdlib/cache is due to the lack of pluggable/test time sources, leading to non-deterministic behavior. This can be addressed by using EventuallyWithT from the testify package to ensure conditions are met within a specified time frame, as seen in the recent pull request #5438.

Would you like more details on how to implement this fix?

Sources:

• Fix flaky auto_refresh_test
• auto_refresh_test.go

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @RunLLM to ask follow-up questions. See runllm.com for more!

[eapolinario]

@Sovietaced , this is a great idea. We should integrate https://pkg.go.dev/k8s.io/utils/clock/testing as part of these tests. Example in https://github.com/kubernetes/client-go/blob/master/util/workqueue/rate_limiting_queue_test.go#L26.

Do you want to give this a try?