Summary

Fixes an intermittent CI failure in three integration tests (an example can be found here: https://github.com/operator-framework/java-operator-sdk/actions/runs/26563951370/job/78253684721?pr=3383):

• ExternalStateIT.reconcilesResourceWithPersistentState
• ExternalStateDependentIT.reconcilesResourceWithPersistentState (extends ExternalStateTestBase)
• ExternalStateBulkIT.reconcilesResourceWithPersistentState

Symptoms in CI:

Expected size: 1 but was: 2 in:
[io.javaoperatorsdk.operator.support.ExternalResource@4f234290,
 io.javaoperatorsdk.operator.support.ExternalResource@3370ff56] within 10 seconds.

The same ExternalResource@3370ff56 instance hash showed up in all three failures, which is the giveaway: an ExternalResource object was outliving the test that created it.

Root cause

operator-framework/src/test/java/io/javaoperatorsdk/operator/support/ExternalIDGenServiceMock.java is a JVM-lifetime singleton with a mutable ConcurrentHashMap field:

public class ExternalIDGenServiceMock {
  private static final ExternalIDGenServiceMock serviceMock = new ExternalIDGenServiceMock();
  private final Map<String, ExternalResource> resourceMap = new ConcurrentHashMap<>();
  // ...
  public static ExternalIDGenServiceMock getInstance() { return serviceMock; }
}

Each external-state test creates resources through getInstance().create(...) (entered into resourceMap) and expects the reconciler's cleanup path to remove them after the custom resource is deleted. Cleanup is asynchronous, so when the next test runs there is a race window in which the previous test's ExternalResource is still in the map. The next test creates its own resource, sees two entries, and Awaitility times out after 10 s.

Fix

Three small, test-only changes:

1. Add a reset() method to ExternalIDGenServiceMock that clears the internal map.
2. Call it from a @BeforeEach in ExternalStateTestBase (covers both ExternalStateIT and ExternalStateDependentIT).
3. Call it from a @BeforeEach in ExternalStateBulkIT (which does not extend the base).

Concurrency note

JOSDK does not enable JUnit 5 parallel execution (no junit-platform.properties, no junit.jupiter.execution.parallel.* properties in any pom.xml). The flake addressed here is a sequential test-ordering issue, not a parallel-execution one, and the BeforeEachCallback is sufficient given that constraint. If parallel execution is ever enabled, the singleton would need to be replaced by per-test instances rather than relying on reset().

Test plan

• mvn -pl operator-framework verify -Dit.test=ExternalStateIT,ExternalStateDependentIT,ExternalStateBulkIT passes locally on a clean checkout.
• No other tests use ExternalIDGenServiceMock.