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 🤣