Support Default Variants in OpenFeature Providers

[ChrisMcD1]

Problem

I see that in #3271 there is an unchecked box about adding support for default variants to OpenFeature providers.

It appears from the latest Java lib and Go lib they both only check the resp.match is true. Given that the resp.match == false for default variants this means you can never get served the value of the default variant, and it falls back to the client side default.

Which major version?

v1

Ideal Solution

The simple fix is to just add a bit to those if statements checking resp.reason == DEFAULT_EVALUATION_REASON and then to use the provided value if so.

Search

• I searched for other open and closed issues before opening this

Additional Context

No response

[dosubot]

You are correct that, as of now, both the Java and Go OpenFeature provider implementations for Flipt only check if resp.match is true, which means the value of the default variant is never served when resp.match == false—even if the evaluation reason is DEFAULT_EVALUATION_REASON. This causes the SDK to fall back to the client-side default instead of using the server-provided default variant.

The Flipt backend and OFREP protocol already support distinguishing between a targeting match and a default variant scenario. The evaluation response includes both a match field and a reason field, where the reason can be DEFAULT_EVALUATION_REASON (or DEFAULT in OFREP) to indicate that the default variant should be served when no targeting rule matches. This is reflected in the protobuf definitions and the evaluation logic on the server side (see source, see source).

Tests in the Flipt codebase confirm that when the evaluation reason is DEFAULT, the response includes the correct variant and value for the default case (see source).

To address this in the OpenFeature providers, you should update the relevant if statements in the Java and Go SDKs to also check if resp.reason == DEFAULT_EVALUATION_REASON (or the equivalent in the SDK's enum). If so, use the provided value from the response as the evaluated flag value, rather than falling back to the client-side default. This will ensure that default variants configured in Flipt are respected and served correctly to clients.

There are currently no open or closed issues or recent PRs in the Flipt repository that address this specific gap. Your proposed solution aligns with the backend's intended behavior and the protocol's design.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}