EventDetails.fromProviderEventDetails drops errorCode, so API-level handlers never see it

[yuchou87]

Summary

EventDetails.fromProviderEventDetails(...) does not copy errorCode, so a handler
registered at API level — OpenFeatureAPI.onProviderError(Consumer<EventDetails>) —
always sees details.getErrorCode() == null, even when the provider explicitly emitted
one.

message, flagsChanged, providerName and eventMetadata all arrive intact. Only
errorCode is lost, and it is lost silently: EventDetails extends
ProviderEventDetails, so getErrorCode() compiles and returns null rather than
failing to compile.

Environment

• dev.openfeature:sdk 1.22.0

Steps to reproduce

Emit an error event carrying an explicit code from any EventProvider (here a probe
extending InMemoryProvider, which is already an EventProvider):

probe.emitProviderError(ProviderEventDetails.builder()
        .errorCode(ErrorCode.PROVIDER_NOT_READY)
        .message("connect refused")
        .build());

Log it from an API-level handler:

OpenFeatureAPI.getInstance().onProviderError(details ->
        log.error("event=PROVIDER_ERROR provider={} message={} error_code={}",
                details.getProviderName(), details.getMessage(), details.getErrorCode()));

Observed:

event=PROVIDER_ERROR provider=InMemoryProvider message=connect refused error_code=null

message arrives, which rules out "the event never got delivered".

Root cause

EventDetails.fromProviderEventDetails(...) is the only path from a provider-emitted
ProviderEventDetails to the EventDetails handed to API-level handlers, and its
builder chain simply does not mention errorCode (EventDetails.java on main):

static EventDetails fromProviderEventDetails(
        ProviderEventDetails providerEventDetails, String providerName, String domain) {
    return builder()
            .domain(domain)
            .providerName(providerName)
            .flagsChanged(providerEventDetails.getFlagsChanged())
            .eventMetadata(providerEventDetails.getEventMetadata())
            .message(providerEventDetails.getMessage())
            .build();
}

ProviderEventDetails has four fields; three of them are copied. Decompiling 1.22.0
shows the same five-field builder chain, so the observed behaviour and the source agree,
and the two lines of evidence are independent of each other.

Why it cannot be worked around

• API-level handlers receive EventDetails; the original ProviderEventDetails is not
  reachable from there.
• There is no public way to observe a provider's events directly —
  EventProvider.setEventProviderListener and EventProvider.attach are both
  package-private.
• Recovering the code by parsing message is not viable: that text is entirely up to
  each provider.

So until this is fixed, an application consuming provider events in Java has no error
code available at all.

Note: the Go SDK does not drop it

openfeature.EventDetails in the Go SDK carries ErrorCode directly, so the
equivalent handler there does receive it. This is an SDK-level divergence between the
two implementations rather than a difference in how applications are written.

Suggested fix

Add the missing line to the builder chain:

.errorCode(providerEventDetails.getErrorCode())

One line, and I checked the two things that would have made it bigger than that.

errorCode is the only field affected. ProviderEventDetails declares exactly four
fields — flagsChanged, message, eventMetadata, errorCode — and the builder chain
transfers the first three. There is no second omission, so this is a missing line rather
than a conversion that needs realigning.

Populating it does not make SDK-generated events ambiguous. The events the SDK raises
itself build a ProviderEventDetails carrying no error code
(OpenFeatureAPI.java:307 and :320), so their getErrorCode() stays null exactly as
it is today. The only thing that changes is that a code a provider explicitly set now
survives the conversion.

Still present on main

Confirmed by reading the source at 5bf9f56, not only the 1.22.0 bytecode:
EventDetails.fromProviderEventDetails still has no .errorCode(...) in its builder
chain, and all three call sites (OpenFeatureAPI.java:531, :535, :543) go through it.

Happy to open a PR.

[yuchou87]

Update while preparing the fix: there is a second place that drops the code, and it is worth folding into the same change.

OpenFeatureAPI.emitError raises PROVIDER_ERROR when a provider fails to initialise. It takes an OpenFeatureError, which exposes getErrorCode(), but builds its event details from the message alone:

private void emitError(FeatureProvider provider, OpenFeatureError exception) {
    runHandlersForProvider(
            provider,
            ProviderEvent.PROVIDER_ERROR,
            ProviderEventDetails.builder().message(exception.getMessage()).build());
}

So even with the conversion fixed, a PROVIDER_ERROR the SDK raises itself still reaches handlers with errorCode == null — including for FatalError and ProviderNotReadyError, where the code is exactly what a handler would act on. Spec 5.1.5 asks for it to be populated, and it is unannotated anywhere in the test suite today.

This corrects something I wrote above. I said populating the field would not change SDK-generated events, on the grounds that they carry no code. That is true of emitReady, which genuinely has none, but not of emitError, which has one and discards it.

The PR therefore covers both, and adds errorCode to EventsTest.shouldHaveAllProperties — the existing test that should have caught this in the first place. Happy to split the emitError half out if you would rather keep the two separate.