Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(feature flags) : Local evaluation : guard for null values when comparing person Properties #249

Merged
merged 5 commits into from
Aug 20, 2024

Conversation

Phanatic
Copy link
Contributor

Problem

The current behavior of stringifying undefined and null values to compare with operators can lead to invalid results in local evaluation.

This causes local evaluation to return true, while the /decide API does the right thing and returns false for undefined values in these properties.

Customer reported that local evaluation always evaluates a condition to true, when it should evaluate to false.
The conditions in question are :

[
    {
        "key": "latestBuildVersion",
        "type": "person",
        "value": ".+",
        "operator": "regex"
    },
    {
        "key": "latestBuildVersionMajor",
        "type": "person",
        "value": "23",
        "operator": "gt"
    },
    {
        "key": "latestBuildVersionMinor",
        "type": "person",
        "value": "31",
        "operator": "gt"
    },
    {
        "key": "latestBuildVersionPatch",
        "type": "person",
        "value": "0",
        "operator": "gt"
    }
]

And the person properties passed into local evaluation are :

{
    "personProperties": {
        "latestBuildVersion": undefined,
        "latestBuildVersionMajor": undefined,
        "latestBuildVersionMinor": undefined,
        "latestBuildVersionPatch": undefined
    } as unknown as Record<string, string> 
}

Since we stringify all of the undefined values, the above call returns true when it should return false because the property values are undefined and not the string undefined.

Changes

Add a NULL_VALUES_ALLOWED_OPERATORS array of operators that allow NULL/UNDEFINED values which is just is_not right now . Any other operator will fail if the overrideValue is null or undefined

Release info Sub-libraries affected

Bump level

  • Major
  • Minor
  • Patch

Libraries affected

  • All of them
  • posthog-web
  • posthog-node
  • posthog-react-native

Changelog notes

  • Local feature flag evaluation will return false for undefined or null property values.

@Phanatic Phanatic requested review from neilkakkar and a team August 19, 2024 14:48
@Phanatic Phanatic force-pushed the check-for-null-property-values branch from 2e1c5c8 to 3bf2498 Compare August 19, 2024 15:18
Copy link

github-actions bot commented Aug 19, 2024

Size Change: +366 B (+0.5%)

Total Size: 73.3 kB

Filename Size Change
posthog-node/lib/index.cjs.js 20 kB +183 B (+0.92%)
posthog-node/lib/index.esm.js 19.9 kB +183 B (+0.93%)
ℹ️ View Unchanged
Filename Size
posthog-web/lib/index.cjs.js 16.7 kB
posthog-web/lib/index.esm.js 16.7 kB

compressed-size-action

Copy link
Contributor

@dmarticus dmarticus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me, one minor formatting change! Thanks for the deep dive! Wonder if any of our other SDKs have this problem...

posthog-node/src/feature-flags.ts Outdated Show resolved Hide resolved
Phanatic and others added 3 commits August 20, 2024 16:13
@Phanatic Phanatic enabled auto-merge (squash) August 20, 2024 21:53
@Phanatic Phanatic merged commit 092e786 into main Aug 20, 2024
3 of 4 checks passed
@Phanatic Phanatic deleted the check-for-null-property-values branch August 20, 2024 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants