fix(tests): Make EventCorrelatorTest timestamps deterministic

[flrnd]

Notes

Replace Thread.sleep(100) with an explicit timestamp increment. The test only requires distinct timestamps to verify event compression, not actual elapsed time.

CI failures

The initial change used plusNanos(10) to separate the timestamps. While the tests passed on Linux and macOS across JDK 11, 17, and 21, and on Windows with JDK 11, CI reported failures on Windows with JDK 17 and 21.

The failures were not consistently reproducible locally, even when using a comparable environment:

• Windows 10 VM
• Same Bazel version as CI, using --config ci
• Eclipse Temurin JDK 11, 17, and 21

Investigation

To investigate, I instrumented EventCorrelatorTest and EventAggregator to compare the generated timestamps, test inputs, and correlated outputs.

The observations were:

• With plusNanos(0), the duplicate-event cases (counts 2 and 11) failed because the correlated events had identical firstTimestamp and lastTimestamp values.
• With plusNanos(1000) (1 μs), both cases passed, and the correlated outputs preserved the expected timestamp difference.
• Five additional uncached executions with the 1 μs increment passed locally.
• The aggregator generates its own timestamps, but in the duplicate-event path, it preserves the incoming event timestamps. The explicit increment therefore reaches the correlated output.

These results confirm that explicitly separating the input timestamps addresses the observed assertion failure. However, they do not fully explain why the original 10 ns increment failed intermittently in CI.

Final adjustment

Increase the increment to 1 ms using:

now = now.plusNanos(1_000_000);

This provides a larger, explicit separation between timestamps while keeping the test independent of execution timing.

The tests pass locally with Eclipse Temurin JDK 11, 17, and 21 on Windows using Bazel's CI configuration.

This removes the reliance on Thread.sleep(100) and avoids depending on consecutive calls to the system clock to produce distinct timestamps.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: flrnd / name: flrnd (fd34a69)

[kubernetes-prow]

Welcome @flrnd!

It looks like this is your first PR to kubernetes-client/java 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-client/java has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[brendandburns]

/lgtm
/approve

[flrnd]

The same failure occurs on Java 11, 17, and 21 in the Windows Bazel build.
In Java 21, two parameterized cases fail because firstTimestamp and lastTimestamp are equal after removing the Thread.sleep(100). It seems that OffsetDateTime.now() calls can produce the same timestamp in this environment.

In this case, I now wonder if it is worth finding a deterministic way to generate the timestamps, or if leaving the sleep in place makes sense.

[flrnd]

Another alternative to Thread.sleep(100) would be to explicitly advance the timestamp used by the test:

@@ -144,8 +138,8 @@ class EventCorrelatorTest {
       Boolean expectedSkip)
       throws Exception {
     EventCorrelator correlator = new EventCorrelator();
+    OffsetDateTime now = OffsetDateTime.now();
     for (CoreV1Event event : previousEvents) {
-      OffsetDateTime now = OffsetDateTime.now();
       event.setFirstTimestamp(now);
       event.setLastTimestamp(now);
       Optional<MutablePair<CoreV1Event, V1Patch>> result = correlator.correlate(event);
@@ -153,7 +147,7 @@ class EventCorrelatorTest {
         correlator.updateState(event);
       }
     }
-    OffsetDateTime now = OffsetDateTime.now();
+    now = now.plusNanos(10);
     newEvent.setFirstTimestamp(now);
     newEvent.setLastTimestamp(now);

[brendandburns]

Feel free to try that alternate fix and update this PR.

[brendandburns]

/lgtm
/approve

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, flrnd

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [brendandburns]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[brendandburns]

There are now test failures in this test in some CI/CD runs.

[kubernetes-prow]

New changes are detected. LGTM label has been removed.