search

PostHog / posthog-node

Official PostHog Node library
MIT License
21 stars 19 forks source link

InconclusiveMatchError when computing flag locally #83

Closed SebTVisage closed 1 year ago

SebTVisage commented 1 year ago

Hi.

We've been seing this error a bit randomly in production since we updated from posthog-node 2.2 to 2.4.

Here's a full error example with stack trace:

InconclusiveMatchError when computing flag locally: job-mode-access: Error: Can't determine if feature flag is enabled or not with given properties
      at FeatureFlagsPoller.<anonymous> (/node_app/back/common/node_modules/posthog-node/lib/index.cjs.js:1469:27)
      at step (/node_app/back/common/node_modules/posthog-node/lib/index.cjs.js:140:27)
      at Object.next (/node_app/back/common/node_modules/posthog-node/lib/index.cjs.js:89:53)
      at fulfilled (/node_app/back/common/node_modules/posthog-node/lib/index.cjs.js:70:28)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

The SDK is initialised with both the API key and personal ApiKey (no identify call) . And we use 2 methods related to FFs: getFeatureFlagValue('ff-key', 'distinct-user-id') and getAllFlags('distinct-user-id').

Calling these methods seems to work fine, we couldn't reproduce any error where we'd get the wrong FF value. Though very little testing was done. The error seems to come from the SDK's polling logic based on the stack trace, but why would it happen? I couldn't find any documentation about this error.

neilkakkar commented 1 year ago

Hey @SebTVisage - this shouldn't be in console.error, but in the debug log. I will fix, thanks!

(It basically means we couldn't compute the flag locally, and thus have to go to our endpoints to get the value instead). Only occurs when the personal API key is set, and you call a flag that has properties which were not passed in.

SebTVisage commented 1 year ago

Oh I see. It's actually a console.warn in the source code. Btw, if the SDK could offer an option to pass a custom logger instead of using the console that would be awesome 🙏

Also, I've never understood local evaluations of FFs as described here. How am I supposed to know what group/person properties to pass in the third parameter? Isn't the distinct id enough? I assumed that we fetched the user flags once from posthog, they always resolve them locally. And they would be up to date via polling. But I guess this assumption is wrong.

neilkakkar commented 1 year ago

Makes sense!

You pass in groups and person properties you know of, and that are used in the flag. If flags don't depend on these, you don't need to pass them in. (so yes for non-group flags without properties, distinct ID is enough).

Polling updates flag definitions, not the values for people (one is a limited data set, the other is almost infinite), and then evaluates whether the current distinct ID will resolve or not.