Non-string data types don't work in local feature flag evaluation

[euporos]

Diagnosis

I'm running into an issue during local evaluation of feature flag definitions containing boolean or numeric values. We have the following feature flag definition:

Surprisingly the following call returns False:

posthog.feature_enabled('testflag', posthog_identity, only_evaluate_locally=True, person_properties={"salutation": "Frau", "has-budget-account?": True}

Workaround

I get the expected result when I cast the boolean to a string, so the following

posthog.feature_enabled('testflag', posthog_identity, only_evaluate_locally=True, person_properties={"salutation": "Frau", "has-budget-account?": "true"})

will return True.

I found the same to be happening with numeric values. Interestingly enough, numerical comparisons (<, >) do work with the stringified values.

Clue:

Setting breakpoints in the PostHog library we found that the feature flag definitions, as polled from the PostHog backend, already contain strings:

{'properties': [{'key': 'salutation',
                        'operator': 'exact',
                        'type': 'person',
                         'value': ['Frau']},
                {'key': 'has-budget-account?',
                        'operator': 'exact',
                        'type': 'person',
                        'value': ['true']}],
               'rollout_percentage': None,
               'variant': None}

So maybe the problem occurs further upstream. It seems that feature flag UI doesn't enforce any datatype unless a numeric comparison is part of the definition, in which case a numeric value is required. In all other cases, any string is accepted. For the boolean field mentioned I can enter true, True or abcde. There is no telling if a value is parsed into a data type other than a string.

System information

posthog python library: 3.8
PostHog backend (self-hosted): 1.43.0

[neilkakkar]

Hey @euporos , indeed, the 'problem' is that the UI sets all types as strings, which are propagated downstream. So the flag definition treats everything as a string.

It doesn't seem like flag matching supports numeric operations for > and <; we'll possibly create new operators for numeric types, like we do for date comparison