Feature request
Please support JSON array/list defaults and results in the Elixir SDK's structured-value evaluation API.
Current behavior
OpenFeature.Client.get_map_value/4 and get_map_details/4 require is_map(default). Passing a list such as [] raises FunctionClauseError before the provider is called:
client = OpenFeature.get_client()
OpenFeature.Client.get_map_value(client, "array-flag", [])
OpenFeature.Client.get_map_details(client, "array-flag", [1, 2])
The guards are present in 0.1.3 and current main:
A provider can already return a list when the caller passes a map default, because the client does not restrict the returned value. However, callers cannot provide a fallback with the same shape as an array payload.
Use case
We are adding JSON array payload support to PostHog's Elixir OpenFeature provider in PostHog/posthog-elixir#216, following the initial provider in PostHog/posthog-elixir#214.
We verified an array payload can be returned through the real client using %{} as the default. We would like users to pass [] or a populated list instead, so a failed evaluation can return an array fallback rather than a map.
Python SDK precedent
The Python SDK already accepts Sequence[FlagValueType] | Mapping[str, FlagValueType] defaults and results for get_object_value and get_object_details, including their async variants:
https://github.com/open-feature/python-sdk/blob/db30b14e3433a53ac37e4940d00cbfe67c3e4731/openfeature/client.py#L342-L399
We also verified that empty and nonempty list defaults work through the Python client in openfeature-sdk 0.10.0.
Suggested behavior
Please consider either widening the existing map getters or introducing an object/structured-value API that accepts both maps and JSON-compatible lists, while preserving existing map calls. The public types, provider callback contract, and documentation should reflect whichever API is chosen.
Suggested test coverage:
- Empty and populated list defaults reach the provider.
- List results, including nested JSON arrays/objects, are returned unchanged.
- Failed evaluations return the supplied list default in both value and details getters.
- Existing map defaults and results keep working.
This request is separate from error-hook behavior and does not require any PostHog-specific handling.
Feature request
Please support JSON array/list defaults and results in the Elixir SDK's structured-value evaluation API.
Current behavior
OpenFeature.Client.get_map_value/4andget_map_details/4requireis_map(default). Passing a list such as[]raisesFunctionClauseErrorbefore the provider is called:The guards are present in 0.1.3 and current main:
A provider can already return a list when the caller passes a map default, because the client does not restrict the returned value. However, callers cannot provide a fallback with the same shape as an array payload.
Use case
We are adding JSON array payload support to PostHog's Elixir OpenFeature provider in PostHog/posthog-elixir#216, following the initial provider in PostHog/posthog-elixir#214.
We verified an array payload can be returned through the real client using
%{}as the default. We would like users to pass[]or a populated list instead, so a failed evaluation can return an array fallback rather than a map.Python SDK precedent
The Python SDK already accepts
Sequence[FlagValueType] | Mapping[str, FlagValueType]defaults and results forget_object_valueandget_object_details, including their async variants:https://github.com/open-feature/python-sdk/blob/db30b14e3433a53ac37e4940d00cbfe67c3e4731/openfeature/client.py#L342-L399
We also verified that empty and nonempty list defaults work through the Python client in
openfeature-sdk0.10.0.Suggested behavior
Please consider either widening the existing map getters or introducing an object/structured-value API that accepts both maps and JSON-compatible lists, while preserving existing map calls. The public types, provider callback contract, and documentation should reflect whichever API is chosen.
Suggested test coverage:
This request is separate from error-hook behavior and does not require any PostHog-specific handling.