[Bug] OpenFeatureClient _typecheck_flag_value incorrectly raises type mismatch between int and float

[fpiche]

Hi there! First of all thank you to the maintainers for OpenFeature, its great :)

I've recently run into an issue where if the flag provider returns an int but the default value of the flag is a float, a TypeMismatchError is raised:

openfeature.exception.TypeMismatchError: Expected type <class 'float'> but got <class 'int'>

This can happen when the flag backend doesn't have float and int types but rather just a "number" type. For example in the Launch Darkly UI, setting a value of 1 results in this error from Openfeature, but 1.000001 works fine. (Note that Launch Darkly doesn't allow float values such as 1.0 they get automatically converted to an int (1), leading to the error)

Would it be possible for Openfeature to gracefully cast integer values to floats?

[beeme1mr]

Hey @fpiche, thanks for reporting this. For situations like you reported, it makes sense to cast integers to floats. FYI @open-feature/technical-steering-committee, is this something we should add to the spec? Do you have any concerns about supporting this cast?

By the way, does the error you reported bubble up to user land? The reason I'm asking is that evaluations should return the default value if an error occurs and I want to make sure that's working as intended.

[fpiche]

Yes it causes issues for users that are acutally kind of insidious.. From the flag provider point of view (example: Launch Darkly UI) we can see that the flag value was returned making you think that all is good :D but actually we saw that in our application logs we were using the default value. So its easy to accidentally end up with the default value while thinking you're using some override, which is quite dangerous

[fpiche]

One other piece of context that might be relevant is that the launch darkly openfeature provider tries to handle this gracefully on their side https://github.com/launchdarkly/openfeature-python-server/blob/main/ld_openfeature/provider.py#L165-L166 , but ultimately the check on the openfeature client side results in error.

[thomaspoignant]

Hey @fpiche, thanks for reporting this. For situations like you reported, it makes sense to cast integers to floats. FYI @open-feature/technical-steering-committee, is this something we should add to the spec? Do you have any concerns about supporting this cast?

My opinion on that is that it is important for the SDKs to respect exactly the types and this seems to be a normal behavior to throw an error if you ask for an int and the provider give you a float.

But I also think that this does not work for every feature flag management systems and from my point of view this is the responsibility of the provider to deal with the casting if it is needed.

[fpiche]

this seems to be a normal behavior to throw an error if you ask for an int and the provider give you a float.

Yes however here we have the inverse case where we ask for a float and the provider gives you us an int. Isn't it safe to assume that we can simply cast it to float? Especially since some providers don't distinguish between them. In the Launch Darkly UI for example you can't create 1.0 it will automatically convert to 1.

my point of view this is the responsibility of the provider

Is there some overlapping responsibilities here then? The ld provider seems to be trying to to a type check as I linked above, however it has different semantics than the type check being performed by the opensearch client

[fpiche]

IMO even if the flag provider did correctly propagate the value as a float back to the openfeature client its still not desirable behaviour to throw on a type mismatch between int and floats when the decimal value is 0. If the error stays, then it means that any user of the feature flag backend (who might be non-technical product managers clicking in a UI, who might not know the difference between floats and ints) needs to know that if they put "1" instead of "1.0" the default value will be used instead, despite all signals on the flag backend side showing that their override is used.

[thomaspoignant]

The main issue for me is if you have multiple variant convoying int and float.
Let's say you have something like:

• Variant A = 1.0
• Variant B = 2.0
• Variant C = 3.1

I understand that requesting an int will work correctly for variant A and B, but for C you have to cast and the value you provide in the evaluation will not be the one from the flag management system (which is a problem from my point of view).

So if we accept casting only if the value is the same, we may have an issue for all users being on variant C.

This is why I am not a big fan of automatic casting inside the SDK.

[fpiche]

the value you provide in the evaluation will not be the one from the flag management system

Fair point for casting floats to ints, however thats not the issue here. We don't need to cast float to int and risk changing the value 🤔 Its the opposite scenario where we receive an int and are expecting a float. It should be safe to convert an int to a float

[thomaspoignant]

Fair point for casting floats to ints, however thats not the issue here. We don't need to cast float to int and risk changing the value 🤔 Its the opposite scenario where we receive an int and are expecting a float. It should be safe to convert an int to a float

true, in that order I think that's ok to do the casting even if I still think this is the provider responsibility to do it.
But I know LD is not doing any difference between float and int, they just have numbers.

[fpiche]

still think this is the provider responsibility to do it

Fair, and I agree, however the current type check on the openfeature.client side is preventing the ld provider from making that decision, since the client is more restrictive with the types. 😄

[aechenak]

Fair point for casting floats to ints, however thats not the issue here. We don't need to cast float to int and risk changing the value 🤔 Its the opposite scenario where we receive an int and are expecting a float. It should be safe to convert an int to a float

true, in that order I think that's ok to do the casting even if I still think this is the provider responsibility to do it. But I know LD is not doing any difference between float and int, they just have numbers.

Hey exactly so we can do something like this in the LD provider

from numbers import Number

def serialize_value(self, flag_type: FlagType, value: Any) -> Any | None:
        if flag_type == FlagType.BOOLEAN and isinstance(value, bool):
                return value
        elif flag_type == FlagType.STRING and isinstance(value, str):
                return value
       # The provider returns a generic Number type; we handle potential int/float mismatches here.
        elif flag_type == FlagType.INTEGER and isinstance(value, Number) and not isinstance(value, bool):
                return int(value)
        elif flag_type == FlagType.FLOAT and isinstance(value, Number) and not isinstance(value, bool):
                return float(value)
        elif flag_type == FlagType.OBJECT and isinstance(value, (dict, list)):
                return value

        return None 

This ensures safe, user-friendly casting for numeric flags, making it easier for users to define values without worrying about int vs float mismatches coming from LaunchDarkly

[beeme1mr]

I'm in favor of this. Would you mind opening a PR? Fyi @toddbaert @kinyoklion

[chenak-a]

While testing this feature, I noticed we were testing this use case (issue). The test was passing because Python considers 2 == 2.0 as True, so it wasn’t catching the type difference. To improve the test and avoid this silent bug, we are adding an explicit type check on the result.

the PR is ready

[beeme1mr]

Cool! I'll close this PR for now, and we can reevaluate if we should update the SDK if other providers are impacted. Thanks everyone!