The OpenFeature spec v0.9.0 moved lifecycle event ownership to the provider: a provider emits its own PROVIDER_READY/PROVIDER_ERROR and the SDK derives provider status entirely from that event stream, but only for providers that implement an SDK-defined opt-in marker. Providers without the marker keep the legacy path, where the SDK emits synthetic lifecycle events after initialize returns.
See spec appendix E, requirement 5.3.5 and provider status 2.8, from open-feature/spec#385 and open-feature/spec#408.
The OpenFeature Java SDK has not implemented the marker yet. In 1.22.1, FeatureProviderStateManager.initialize sets READY itself and ProviderRepository unconditionally invokes the afterInit consumer, which is OpenFeatureAPI.emitReady; nothing consults the provider. The work is tracked, unstarted, in open-feature/java-sdk#1999 ("Spec v0.9.0 compliance").
That constraint is why this provider currently suppresses its own ready emit while initialize is running (#63): with no marker available, a provider that emits ready during initialization gets a duplicate from the SDK, which appendix E describes as expected legacy behavior for that mixed mode.
Once the Java SDK ships the marker, that suppression should be inverted:
- Implement the opt-in marker.
- Emit
PROVIDER_READY from the provider when the data source becomes valid, including during initialize, and PROVIDER_ERROR when initialization fails or the start wait lapses.
- Remove the
initializing flag and the duringInitialization check in handleDataSourceStatus.
- Confirm no duplicate ready or error events reach consumers, and that provider status still tracks the data source for later stale/error/valid transitions.
Blocked on open-feature/java-sdk#1999. No action possible until the marker exists in a released SDK inside our supported dependency range.
The OpenFeature spec
v0.9.0moved lifecycle event ownership to the provider: a provider emits its ownPROVIDER_READY/PROVIDER_ERRORand the SDK derives provider status entirely from that event stream, but only for providers that implement an SDK-defined opt-in marker. Providers without the marker keep the legacy path, where the SDK emits synthetic lifecycle events afterinitializereturns.See spec appendix E, requirement 5.3.5 and provider status 2.8, from open-feature/spec#385 and open-feature/spec#408.
The OpenFeature Java SDK has not implemented the marker yet. In 1.22.1,
FeatureProviderStateManager.initializesetsREADYitself andProviderRepositoryunconditionally invokes theafterInitconsumer, which isOpenFeatureAPI.emitReady; nothing consults the provider. The work is tracked, unstarted, in open-feature/java-sdk#1999 ("Spec v0.9.0 compliance").That constraint is why this provider currently suppresses its own ready emit while
initializeis running (#63): with no marker available, a provider that emits ready during initialization gets a duplicate from the SDK, which appendix E describes as expected legacy behavior for that mixed mode.Once the Java SDK ships the marker, that suppression should be inverted:
PROVIDER_READYfrom the provider when the data source becomes valid, including duringinitialize, andPROVIDER_ERRORwhen initialization fails or the start wait lapses.initializingflag and theduringInitializationcheck inhandleDataSourceStatus.Blocked on open-feature/java-sdk#1999. No action possible until the marker exists in a released SDK inside our supported dependency range.