You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our docs mention that disabled flags will return as either null or undefined (https://posthog.com/docs/feature-flags/creating-feature-flags#enable-feature-flag). In reality /decide will simply not include these keys at all (which is technically equivalent to undefined after HTTP transport). It would be more useful for clients to see these keys mapped to null every time, so that SDK users can differentiate between a disabled flag and non-existent flag / posthog error response.
The text was updated successfully, but these errors were encountered:
One thing to consider - people might purposefully want it this way. So that they don't show flag keys that the user shouldn't have access to.
I can't think of a super strong reason why but simply showing all keys might not be what's wanted 🤷
Also many older SDKs don't check the value, they just grab the keys instead. Would need to be sure to make this a version change to the api (or maybe even just make this part of the new flags service instead)
Our docs mention that disabled flags will return as either
null
orundefined
(https://posthog.com/docs/feature-flags/creating-feature-flags#enable-feature-flag). In reality/decide
will simply not include these keys at all (which is technically equivalent toundefined
after HTTP transport). It would be more useful for clients to see these keys mapped tonull
every time, so that SDK users can differentiate between a disabled flag and non-existent flag / posthog error response.The text was updated successfully, but these errors were encountered: