Session Replay batching/queueing should be resilient to page reload

[pauldambra]

We batch replay data in memory. This is normally fine but does mean that someone could miss collecting some data

This is made worse with minimum duration set - you have to stay on page for the minimum duration or you lose data

It also means we couldn't reliably do some features like capture locally until a manual trigger

Let's move the batch/queue to being in a persistent store in the brower

[marandaneto]

We already listen to visibilitychange https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event We can force a store in the cache or force sending the pending data if the visibility is going to the background, reloading, or whatever makes sense to not lose data. Another thing to do is if the network request actually fails due to eg no internet, slow internet, should we retry?

[pauldambra]

so the existing implementation is memory backed and does retry failed sends / stops sending when network is gone etc but sending on page leave is very flaky so we are always going to lose things

tbh I can probably pump the android code into chat gpt and ask it to switch to typescript and store in local storage instead of a file 🤣

[svemat01]

Hey there!

Just checking in on the status of moving the batch/queue to persistent storage (like localStorage or IndexedDB) as discussed earlier in this issue. Is this still on the roadmap?

This feature would be really helpful for us. We have privacy-sensitive use cases where we'd like to initiate recording immediately but keep the data buffered locally by default. We'd then only trigger the actual upload to PostHog if a user experiences an error or explicitly consents to sharing their session afterwards as to not miss any valuable context.

Thanks for any updates!