Mobile Session Replay: Offline support

[bruno-garcia]

tl;dr:

Initial releases of Mobile Replay will not support offline mode. That's because it can't rely on the current offline mode support, in its current form. For that reason we'll start with online only and investigate next steps with offline caching once the product capabilities are more built out.

In buffer mode, we'll write the image files to disk in the disk ring buffer, but in the event of an exception that triggers a replay, we'll check if the device is online before starting the replay (as in: turning those images into videos and creating envelopes for those).

Background

All Sentry mobile SDKs already support offline caching. It works by writing the files to disk before even attempting to send it over the network. If sending is successful, the file is deleted. This also helps make sure the data isn't lost in the event of an app termination by the OS, out of battery, etc. And is a requirement for native crashes where we are not able to send data over the network from the signal handler and our only option is to write to disk and send it on restart.

We have a default maxItems=30 often. That means, 30 envelopes. Each envelope can have more than 1 item (like event + attachment).

Once the count of files on Sentry's cache directory reaches that count, the SDK first deletes the oldest file before writing a new one.

With session replay, we'll be writing a new envelope every 5 seconds, potentially deleting useful crash reports, session update that affects crash free rate, etc. In fact in just 2 and a half minutes offline, if a Session Recording is in place, the whole default cache directory would contain only the replay segments, and the oldest envelope will contain the replay segment 0, which if deleted, turns the whole replay unusable.

[romtsn]

For the first alpha/iteration we fully support offline recording for the buffer mode (errors) and partially support it for the session mode. In the session mode we'll record the first segment (let's say segment_3) after device goes offline and skip everything until the device goes back online. When the devices goes back online (let's say segment_17), we'll send both segment_3 and segment_17, so there will be a gap in the playback, but it should still work normally.

The SDK should not break or have any negative side effects on the other parts of the SDK.

[bruno-garcia]

A thought from another ticket;

do not capture segments while offline, but keep recording and capture longer ones when back online