Closed amerjusupovic closed 6 months ago
Currently, the provider incorrectly expects the string type for a variant's configuration value within a feature flag. This PR allows the provider to correctly handle all possible values for configuration_value.
string
configuration_value
Expected allowed values:
{ "id": "ExampleFlag", "description": "", "enabled": true, "conditions": { "client_filters": [] }, "variants": [ { "name": "NumberValue", "configuration_value": 1 }, { "name": "StringValue", "configuration_value": "1" }, { "name": "ObjectValue", "configuration_value": { "Key1": "Value1" } }, { "name": "ArrayValue", "configuration_value": ["1"] }, { "name": "BooleanValue", "configuration_value": true }, { "name": "NullValue", "configuration_value": null } ] }
Currently allowed values:
{ "id": "ExampleFlag", "description": "", "enabled": true, "conditions": { "client_filters": [] }, "variants": [ { "name": "StringValue", "configuration_value": "1" }, { "name": "NullValue", "configuration_value": null } ] }
What's the bug, no PR description no issue linked
My fault, let me add a description
Currently, the provider incorrectly expects the
string
type for a variant's configuration value within a feature flag. This PR allows the provider to correctly handle all possible values forconfiguration_value
.Expected allowed values:
Currently allowed values: