OpenFeature is a CNCF standard for vendor-agnostic feature flag evaluation. Learn vocabulary for Provider interface abstraction, default values and ERROR/DEFAULT reasons, Hook lifecycle methods (before/after/error/finally), EvaluationContext and Targeting Key for consistent bucketing, and atomic provider transition semantics.
0 / 5 completed
1 / 5
A developer calls client.getBooleanValue('feature-x', false, evaluationContext) via the OpenFeature SDK. What does the second argument represent?
The second argument is the default value. OpenFeature always requires a default value for flag evaluation methods. If the flag is not found, the provider is in an error state, or evaluation throws an exception, the SDK returns this default value along with a reason of DEFAULT or ERROR. This ensures safe fallback behavior.
2 / 5
What is an OpenFeature 'Provider' and how does it relate to a feature flag vendor?
An OpenFeature Provider is a vendor-specific implementation of the FeatureProvider interface. It translates OpenFeature SDK calls into the vendor's native SDK calls (e.g., LaunchDarkly's SDK, Flagsmith's API). This abstraction allows applications to switch flag vendors by swapping the provider without changing application code.
3 / 5
An OpenFeature Hook's before method is called. What can it return to influence flag evaluation?
A Hook's before method can return a modified EvaluationContext to add, change, or enrich context attributes before provider evaluation. For example, a hook could inject the current user's subscription tier from a session cache. Returning undefined leaves the context unchanged. Hooks cannot directly return flag values — only the provider does that.
4 / 5
OpenFeature defines a concept called 'Targeting Key'. What is its purpose in flag evaluation?
The Targeting Key is a standardized field in EvaluationContext that identifies the subject being evaluated — typically a user ID, session ID, or device ID. Feature flag providers use this key for consistent bucketing (ensuring the same user always gets the same variant) and for defining targeting rules ('users in cohort X').
5 / 5
A team uses OpenFeature's setProvider with a new provider while the application is running. What does OpenFeature guarantee about in-flight flag evaluations during provider transition?
OpenFeature's provider transition is atomic from the client's perspective: in-flight evaluations complete using the existing provider, and the new provider handles evaluations only after it has successfully initialized (reached READY state). During the transition, the SDK may use a cached or default state. This prevents partial evaluation inconsistencies during live provider swaps.