-
Notifications
You must be signed in to change notification settings - Fork 138
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(): prevent person processing if /decide fails to fetch remote config #1658
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Size Change: -330 B (-0.01%) Total Size: 3.25 MB
ℹ️ View Unchanged
|
@@ -35,7 +35,7 @@ export const isObject = (x: unknown): x is Record<string, any> => { | |||
// eslint-disable-next-line posthog-js/no-direct-object-check | |||
return x === Object(x) && !isArray(x) | |||
} | |||
export const isEmptyObject = (x: unknown): x is Record<string, any> => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit of an inaccurate use of the is
keyword; my new usage of it in posthog-core.ts
gets mad because a false return from isEmptyObject
tells TS that this.config
is "not an object" when it could instead just be "not an empty object"
Changes
Context:
In digging through the code it appears that there are two cases where this could potentially happen:
_init
settingthis.config = {}
(here) and it getting re-set to the proper value (this seems like an extremely unlikely race condition but we may as well protect against it in_hasPersonProcessing
, and while writing unit tests for a potential fix here I discovered that all events would fail to send ifposthog.config
was an empty object anyway)/decide
fails to return the config values, leaving the SDK to fall back toperson_profiles: 'always'
(here)To protect against the second edge case we make the following change: Remove the dependency on the
defaultIdentifiedOnly
field from/decide
. This is the new default, so we should not need this conditional moving forward anyway.Checklist