Skip to content
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

Respect session replay feature flag after /decide endpoint call #263

Open
ioannisj opened this issue Nov 25, 2024 · 3 comments
Open

Respect session replay feature flag after /decide endpoint call #263

ioannisj opened this issue Nov 25, 2024 · 3 comments
Labels
bug Something isn't working Session Replay

Comments

@ioannisj
Copy link
Contributor

ioannisj commented Nov 25, 2024

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 ioannisj added bug Something isn't working Session Replay labels Nov 25, 2024
@ioannisj
Copy link
Contributor Author

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

@marandaneto
Copy link
Member

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
Copy link
Contributor Author

ioannisj commented Nov 25, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Session Replay
Projects
None yet
Development

No branches or pull requests

2 participants