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
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?
The text was updated successfully, but these errors were encountered:
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
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.
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 tofalse
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?The text was updated successfully, but these errors were encountered: