[BUG] FILE resolver type falls back to default value

[stepheniota]

Description

When using the flagd provider with the FILE resolver type, the feature flag evaluation sometimes returns the default_value instead of the expected variant from our flags.json. For example, if you call .get_boolean_value() multiple times on the same flag name but with different default values, the client falls back to the default instead of returning the configured variant.

Sample code

Sample flags.json:

{
    "$schema": "https://flagd.dev/schema/v0/flags.json",
    "flags": {
        "enable-debug-logs": {
            "defaultVariant": "custom_key",
            "state": "ENABLED",
            "targeting": {
                "if": [
                    {
                        "in": [
                            {
                                "var": "instance"
                            },
                            [
                                "placeholder",
                                "custom_key"
                            ]
                        ]
                    },
                    {
                        "var": "instance"
                    },
                    null
                ]
            },
            "variants": {
                "placeholder": true,
                "custom_key": false
            }
        }
    }
}

Sample code:

from openfeature import api
from openfeature.contrib.provider.flagd import FlagdProvider
from openfeature.contrib.provider.flagd.config import ResolverType
from openfeature.evaluation_context import EvaluationContext

evaluation_ctx = EvaluationContext(
    targeting_key="instance",
    attributes={
        "instance": "custom_key",
    },
)

api.set_evaluation_context(evaluation_ctx)
api.set_provider(
    FlagdProvider(
        resolver_type=ResolverType.FILE,
        offline_flag_source_path="flags.json",
    )
)

client = api.get_client()

print(client.get_boolean_value("enable-debug-logs", default_value=False))
print(client.get_boolean_value("enable-debug-logs", default_value=True))

You should see the output:

False
True

which means the default_value was returned.

Environment details

Python 3.11.11
openfeature-provider-flagd==0.2.0
openfeature_sdk==0.8.0

[stepheniota]

If I play around with it, I can get different configurations to work. For example, if custom_key's flag is defined as true, then I don't notice the fallback error. Rather correct value is returned

[AdityaVallabh]

Looks like a Parse error will be thrown if the value is a boolean False which doesn't look right:

python-sdk-contrib/providers/openfeature-provider-flagd/src/openfeature/contrib/provider/flagd/resolvers/in_process.py

Line 124 in 2f85057

if not value:

[beeme1mr]

Thank @AdityaVallabh, it looks like that logic needs to be improved. Would you be willing to contribute a fix? Feel free to ping me if you have any question. FYI @aepfli

[gruebel]

Yeah, feel free to contribute a fix, otherwise I can handle it. Let me know @AdityaVallabh

[AdityaVallabh]

Sure, let me send in a PR.

[aepfli]

Wow thank you, I will also adapt our gherkin test suite.

[aepfli]

i wanted to add a special test case to our gherkin suite, but this should actually do it already. so we should have seen some flakiness in our e2e tests - i will dig deeper, and see why we have not detected this earlier - anyway i think this is also somewhat special to python. Thank you for discovering and reporting this

[aepfli]

okay, i see, this is related with zero values and targeting - i will adapt the tests to add those cases