Skip to content

Commit c834120

Browse files
authored
feat(develop): Introduce SDK behaviour section for replays
1 parent 2d76c89 commit c834120

File tree

1 file changed

+19
-0
lines changed

1 file changed

+19
-0
lines changed

develop-docs/sdk/telemetry/replays.mdx

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -172,3 +172,22 @@ The other sub-item is the replay recording's instructions set. This payload shou
172172
{"segment_id":0}
173173
/* gzipped JSON payload */
174174
```
175+
176+
## SDK Behavior
177+
178+
### Session mode
179+
180+
When an SDK records Session Replay in `session` mode (`sessionSampleRate` is specified), the recording should start when the SDK is initialized and it should be continuously streamed to the Sentry servers. The SDK should send a replay envelope every 5 seconds. The maximum duration of the recording should not exceed 60 minutes (or 15 minutes without an activity on Web).
181+
182+
For the SDKs that support disk cache, the recording should pause when there's no internet connection or the SDK is getting rate-limited. This is necessary to prevent overflowing the disk cache, which can potentially result in losing more critical envelopes. When internet connection is restored or rate limit is lifted, the recording should resume.
183+
184+
### Buffer mode
185+
186+
When an SDK records Session Replay in `buffer` mode (`onErrorSampleRate` is specified), the recording should start when the SDK is initialized and should be buffered in-memory (and to disk if an SDK supports disk cache) in a ring buffer for up to 30 seconds back. The capturing of the recording may be triggered when one of the following conditions is met:
187+
188+
- A crash or error event occurs and is captured by the SDK
189+
- `flush` API has been called manually on the replay (for SDKs that support manual API)
190+
191+
After the initial (buffered) segment has been captured, the SDK should continue recording in `session` mode. Note, however, that the `replay_type` field of the following segments should still be set to `buffer` to reflect the original `replay_type`.
192+
193+
If the crash or error event has been dropped in `beforeSend`, the replay should **not** be captured.

0 commit comments

Comments
 (0)