chore(flags): Add new debugging property $feature_flag_bootstrapped_response and $feature_flag_bootstrapped_payload to $feature_flag_called event

[havenbarnes]

Problem

When SDK users make use of feature flag bootstrapping, the response shown in the $feature_flag_called event can show different values than what would have been fetched remotely. This can lead to confusion when reviewing flag value breakdown results, for example making it seem as if a flag that is turned completely to true was evaluated to false. These two new event properties are mostly useful for debugging customer issues, but could also be used in product to show users that the response shown came from bootstrapped values, and not /decide

Changes

Nothing functional, just additional event properties

Release info Sub-libraries affected

Bump level

• Major
• Minor
• Patch

Libraries affected

• All of them
• posthog-web
• posthog-node (no server-side bootstrapping)
• posthog-react-native

Changelog notes

• Add new debugging property $feature_flag_bootstrapped_response and $feature_flag_bootstrapped_payload to $feature_flag_called event

[github-actions]

Size Change: +708 B (+0.65%)

Total Size: 109 kB

Filename	Size	Change
posthog-node/lib/index.cjs.js	21 kB	+52 B (+0.25%)
posthog-node/lib/index.esm.js	21 kB	+53 B (+0.25%)
posthog-react-native/lib/posthog-core/src/index.js	10 kB	+114 B (+1.15%)
posthog-react-native/lib/posthog-core/src/types.js	420 B	+55 B (+15.07%)	⚠️
posthog-web/lib/index.cjs.js	17.6 kB	+217 B (+1.25%)
posthog-web/lib/index.esm.js	17.6 kB	+217 B (+1.25%)

ℹ️ View Unchanged

Filename	Size
posthog-react-native/lib/posthog-core/src/eventemitter.js	1.08 kB
posthog-react-native/lib/posthog-core/src/lz-string.js	1.42 kB
posthog-react-native/lib/posthog-core/src/utils.js	822 B
posthog-react-native/lib/posthog-core/src/vendor/uuidv7.js	2.04 kB
posthog-react-native/lib/posthog-react-native/index.js	485 B
posthog-react-native/lib/posthog-react-native/src/autocapture.js	1.8 kB
posthog-react-native/lib/posthog-react-native/src/frameworks/wix-navigation.js	651 B
posthog-react-native/lib/posthog-react-native/src/hooks/useFeatureFlag.js	437 B
posthog-react-native/lib/posthog-react-native/src/hooks/useFeatureFlags.js	362 B
posthog-react-native/lib/posthog-react-native/src/hooks/useLifecycleTracker.js	416 B
posthog-react-native/lib/posthog-react-native/src/hooks/useNavigationTracker.js	628 B
posthog-react-native/lib/posthog-react-native/src/hooks/usePostHog.js	249 B
posthog-react-native/lib/posthog-react-native/src/legacy.js	810 B
posthog-react-native/lib/posthog-react-native/src/native-deps.js	1.17 kB
posthog-react-native/lib/posthog-react-native/src/optional/OptionalAsyncStorage.js	183 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalExpoApplication.js	215 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalExpoDevice.js	211 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalExpoFileSystem.js	224 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalExpoLocalization.js	216 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalReactNativeDeviceInfo.js	220 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalReactNativeNavigation.js	218 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalReactNativeNavigationWix.js	222 B
posthog-react-native/lib/posthog-react-native/src/optional/OptionalSessionReplay.js	231 B
posthog-react-native/lib/posthog-react-native/src/posthog-rn.js	4.16 kB
posthog-react-native/lib/posthog-react-native/src/PostHogContext.js	210 B
posthog-react-native/lib/posthog-react-native/src/PostHogProvider.js	1.57 kB
posthog-react-native/lib/posthog-react-native/src/storage.js	1.09 kB
posthog-react-native/lib/posthog-react-native/src/types.js	90 B
posthog-react-native/lib/posthog-react-native/src/version.js	123 B

_{compressed-size-action}

[havenbarnes]

@dmarticus I'm thinking it may be smart to add an additional property here as well, indicated whether flags have been fetched yet or not at the time of the flag check. Something like $feature_flags_fetched: boolean. Otherwise, we don't have a clear way to know if $feature_flag_response matches $feature_flag_bootstrapped_response because bootstrapping was done correctly, or if the flags have just been fetched already.
WDYT?

[dmarticus]

@dmarticus I'm thinking it may be smart to add an additional property here as well, indicated whether flags have been fetched yet or not at the time of the flag check. Something like $feature_flags_fetched: boolean. Otherwise, we don't have a clear way to know if $feature_flag_response matches $feature_flag_bootstrapped_response because bootstrapping was done correctly, or if the flags have just been fetched already. WDYT?

I love this idea; seems like it couldn't hurt to add this type of metadata to our flags requests – maybe something like used_boostrap_value is more clear than feature_flags_fetched, if the goal is to track that bootstrapping was done correctly. And I think that could be done in a subsequent PR. But I like this!

[dmarticus]

stamped with a comment!

[marandaneto]

@havenbarnes would be cool to add a test case for bootstrap flags and payloads, check the file posthog.featureflags.spec.ts

[havenbarnes]

Thanks @marandaneto , added some tests. Also added the $used_bootstrap_value property discussed above. I'm imitating same behavior as this.instance.decideEndpointWasHit from posthog-js (https://github.com/PostHog/posthog-js/blob/bootstrapped-flag-evt-property/src/posthog-featureflags.ts#L295). I'll wait for your approval!