Respect session replay feature flag after /decide endpoint call

[ioannisj]

Description

Ticket: https://posthoghelp.zendesk.com/agent/tickets/20809

Session recordings start as soon as the app launches, but feature flag evaluation is executed asynchronously.
If the cached value is different that the value returned from /decide endpoint, then the recording may start (and not stop) when the flag evaluates to false

A possible fix is to mem-cache screenshots and skip processing until the /decide API has been successfully called - there are some memory footprint consideration here. We may need to use a different disk-backed queue, and drop or merge the queues once the flag evaluates?

[ioannisj]

@marandaneto Is this relevant to Android/RN as well?

[marandaneto]

Currently, in the absence of a cached value - which is common for fresh installs - session recordings start as soon as the app launches, but feature flag evaluation is executed asynchronously.

This is not the case, in the absence of a cached value, the recording won't start.
sessionReplayFlagActive is only enabled if there was a cached value and it was enabled before.

Similarly, if the cached value is different that the value returned from /decide endpoint, this could lead to a similar effect

This is the current behaviour and this is the issue.

A possible fix is to cache screenshots and skip processing until the /decide API has been successfully called (with an option to stop recording and clear replayQueue if flag is evaluated to false)

Yes, but be aware of the memory footprint since queuing up lots of things might blow up people's apps.
Also if preloadFeatureFlags is disabled, and people don't call reloadFeatureFlags manually or call it much later, everything will be delayed and the memory footprint will be even worsened.
I don't think we should clear replayQueue but rather a memory queue, the replayQueue might have items from previous sessions that were supposed to be recorded anyway.

@marandaneto Is this relevant to Android/RN as well?

Android yes, RN will "obey" the Android and iOS implementation

[ioannisj]

This is not the case, in the absence of a cached value, the recording won't start.
sessionReplayFlagActive is only enabled if there was a cached value and it was enabled before.

Yeah, true! my bad. Updated the description

[marandaneto]

Consider the new remote config endpoint before doing this, might affect implementation