From c8341207f01310c33aa11c87dcc4946e1fa96858 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 25 Jul 2025 15:34:34 +0200 Subject: [PATCH 1/3] feat(develop): Introduce SDK behaviour section for replays --- develop-docs/sdk/telemetry/replays.mdx | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/develop-docs/sdk/telemetry/replays.mdx b/develop-docs/sdk/telemetry/replays.mdx index e668fd955d99c..cbc9c92a9ff0f 100644 --- a/develop-docs/sdk/telemetry/replays.mdx +++ b/develop-docs/sdk/telemetry/replays.mdx @@ -172,3 +172,22 @@ The other sub-item is the replay recording's instructions set. This payload shou {"segment_id":0} /* gzipped JSON payload */ ``` + +## SDK Behavior + +### Session mode + +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). + +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. + +### Buffer mode + +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: + +- A crash or error event occurs and is captured by the SDK +- `flush` API has been called manually on the replay (for SDKs that support manual API) + +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`. + +If the crash or error event has been dropped in `beforeSend`, the replay should **not** be captured. From 17a17a8bac506f23c34bed86aadcd1d84263b476 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 25 Jul 2025 15:36:27 +0200 Subject: [PATCH 2/3] Update develop-docs/sdk/telemetry/replays.mdx --- develop-docs/sdk/telemetry/replays.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/sdk/telemetry/replays.mdx b/develop-docs/sdk/telemetry/replays.mdx index cbc9c92a9ff0f..5a712c8ebfa8f 100644 --- a/develop-docs/sdk/telemetry/replays.mdx +++ b/develop-docs/sdk/telemetry/replays.mdx @@ -183,7 +183,7 @@ For the SDKs that support disk cache, the recording should pause when there's no ### Buffer mode -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: +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 the 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: - A crash or error event occurs and is captured by the SDK - `flush` API has been called manually on the replay (for SDKs that support manual API) From b1e73a9f6369e74378c2f8343f9d534453197b00 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 25 Jul 2025 15:36:43 +0200 Subject: [PATCH 3/3] Update develop-docs/sdk/telemetry/replays.mdx --- develop-docs/sdk/telemetry/replays.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/sdk/telemetry/replays.mdx b/develop-docs/sdk/telemetry/replays.mdx index 5a712c8ebfa8f..8f380c821a878 100644 --- a/develop-docs/sdk/telemetry/replays.mdx +++ b/develop-docs/sdk/telemetry/replays.mdx @@ -177,7 +177,7 @@ The other sub-item is the replay recording's instructions set. This payload shou ### Session mode -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). +When an SDK records Session Replay in `session` mode (`sessionSampleRate` is specified), the recording should start when the SDK is initialized and 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). 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.