fix: Do not emit a redundant ready event during initialization

[kinyoklion]

Stops the provider from emitting a second PROVIDER_READY event during initialization, and makes LifeCycleTest.itCanHandleClientThatIsNotInitializedImmediately wait for the event instead of racing it.

• The provider emitted ready from its data source status listener while initialize was still running, and the OpenFeature SDK emits its own ready event when initialization succeeds — consumers got two.
• The test only passed because it asserted the counter before the second event was dispatched; adding a wait made it fail expected: <1> but was: <2> 25/25 times, which is how the double emit surfaced.
• Ready events for later recoveries (stale/error back to valid) are unaffected — only the emit that happens while initialize is in flight is suppressed.
• Under CPU load, LifeCycleTest now passes 25/25; before this branch it failed 9/25 with expected: <1> but was: <0>.

Implementation details

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Mechanism

initialize sets an initializing flag for the duration of the call. In the VALID branch of handleDataSourceStatus the flag is read before completing the initialization future, so the initialize thread cannot clear it between the read and the emit:

if (emit) {
    boolean duringInitialization = initializing;
    completer.complete(true);
    if (!duringInitialization) {
        emitProviderReady(...);
    }
}

setProviderAndWait also returns before API-level handlers have run, since the OpenFeature SDK dispatches events on its own executor; the test now waits on a CompletableFuture (1s timeout) and then asserts the count after a short grace period so a duplicate emit is still caught.

Alternatives rejected

Dropping the exact-count assertion from the test — it hides exactly the duplicate-emit bug this change fixes.

Testing

./gradlew test --tests '*LifeCycleTest*' --rerun-tasks repeated 25x with six busy loops pinning the CPUs, and the full suite once: all green. On main the same loop failed 9/25 (and 5/20 in an earlier round). CI on this branch was also re-triggered 11 times with empty commits, all green, before the provider change.

Related

Found while investigating #32 (debug output for a flaky itEmitsReadyEvents); that flake did not reproduce in ~75 runs and its debug prints are superseded by #59, so #32 looks closable.

Link to Devin session: https://app.devin.ai/sessions/3c9b094de4f84a0f82ba266098e823e9
Open in Devin Desktop: https://app.devin.ai/desktop/session/3c9b094de4f84a0f82ba266098e823e9?variant=devin
Requested by: @kinyoklion

---

Note

Overview
Fixes double PROVIDER_READY events when the LaunchDarkly data source becomes valid while initialize is still running. The OpenFeature SDK already emits ready on successful initialization; the provider was also calling emitProviderReady from the data-source status listener, so listeners could see two events.

An initializing flag wraps the wait in initialize (cleared in finally). On transition to VALID, the provider still completes initialization and updates state, but skips emitProviderReady while initializing is true. Recoveries after init (e.g. stale/error back to valid) still emit ready as before.

Tests: itCanHandleClientThatIsNotInitializedImmediately now waits for the ready event and rechecks the count after a short delay to catch races. A new case uses a controllable data source to assert that failed init followed by VALID still produces exactly one ready event.

^{Reviewed by Cursor Bugbot for commit f8a6052. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[kinyoklion]

I am concerned that this wouldn't detect if we emitted the ready event multiple times.

[devin-ai-integration]

I am concerned that this wouldn't detect if we emitted the ready event multiple times.

Good catch — and it was already emitting twice. I put the counter back with a short grace period after the awaited event, and it failed expected: <1> but was: <2> 25/25 times: the provider emits ready from the data source status listener while initialize is still running, and the OpenFeature SDK emits its own ready event once initialization succeeds. The old assertion passed only because it ran before the second dispatch.

So this PR now also suppresses the provider's ready emit while initialize is in flight (later stale/error → valid recoveries still emit). With that, LifeCycleTest passes 25/25 under CPU load.

[kinyoklion]

Does a volatile handle all ordering concerns that may apply in this situation?

[devin-ai-integration]

Good catch — a bare volatile was not enough. It gave visibility for the flag itself, but the decision "did this VALID transition happen during initialize?" involves two pieces of state (initializing and state), and reading them at different times leaves a window: the flag could be cleared between the synchronized (stateLock) block that claims the ready transition and the read of initializing just after it, so the initial ready event could be emitted twice.

Latest commit makes the pair atomic instead: initializing is now a plain field always accessed under stateLock, and the "should we emit?" decision is made inside the same critical section that transitions state to READY. initialize writes the flag through setInitializing, which takes the same lock, so the flag write and the state read can't interleave.

Stress run after the change: 25/25 green under CPU load (6 busy loops).