🐛 Manual session replay unavailable

[paco-spr]

Describe the bug

We’re trying to support random replay sampling plus a user-triggered “record this bug now” flow via startSessionReplayRecording({ force: true }).

When startSessionReplayRecordingManually is unset:

• replay data is ingested
• session.has_replay = true
• but the session/view is still marked unavailable in Datadog

When we explicitly set startSessionReplayRecordingManually: true, manual replay works.

SDK version:

• @datadog/browser-rum: 6.30.1
• @datadog/browser-logs: 6.30.1

We tested these scenarios:

sessionReplaySampleRate	sessionSampleRate	startSessionReplayRecordingManually	Outcome
1	100	unset	broken
100	100	unset	works
1	100	true	works

Details:

• 1 / 100 / unset: replay segments are ingested, but the session/view are still marked unavailable
• 100 / 100 / unset: automatic replay works, as long as we do not use the manual replay button
• 1 / 100 / true: manual replay works

This makes it look like startSessionReplayRecording({ force: true }) is not producing a replayable session/view unless manual replay mode is explicitly enabled.

Observed session metadata for affected sessions:

• session.has_replay = true
• session.is_replay_available = false
• session.has_full_snapshot = false
• replay stats present
• _dd.initial_view_with_replay.id present
• _dd.session.has_view_marked_as_replay = false

Affected examples:

• Session: db53f823-c8eb-460e-8f84-18e49f7ef911
• Session: 0747d073-4103-4be7-9e6e-daaac3647f32
• View: 8d9306cf-e555-4621-88a5-172f3205fa21

To Reproduce
Steps to reproduce the behavior:

Initialize:

datadogRum.init({
  ...,
  sessionSampleRate: 100,
  sessionReplaySampleRate: 1,
  // startSessionReplayRecordingManually is unset
})

Then:

1. Load the app and start a new session
2. Trigger manual replay with:

datadogRum.startSessionReplayRecording({ force: true })

3. Interact with the app for a bit
4. Stop replay / inspect the resulting session in Datadog
5. Open the session replay or replay tab for the recorded session/view

Expected behavior

We expect random replay sampling to continue working normally, and startSessionReplayRecording({ force: true }) to make the current session replayable when a user explicitly triggers recording, even when startSessionReplayRecordingManually is unset. Instead, replay data is ingested but the resulting session/view is still marked unavailable.

[paco-spr]

Update, I did some further debugging and I'm no longer sure that setting startSessionReplayRecordingManually: true is what fixes the issue. I still don't really understand how I can end up in this state:

session.has_replay = true
session.is_replay_available = false

[Sacha924]

Hey @paco-spr our team saw your reported issue
I'll take a look at it next week as soon as I can. Thanks for the detailed repro steps and session examples, that'll help a lot.

[Sacha924]

Hey @paco-spr , thanks for the detailed report. I spent some time investigating this.

I tried to reproduce the exact scenario (sessionReplaySampleRate: 1, startSessionReplayRecordingManually unset, then calling startSessionReplayRecording({ force: true })) and was unable to; the session replay was available on my end.

Looking at the session metadata you shared, I believe what's happening is:

• session.has_replay = true means the SDK was actively recording and tagged RUM events accordingly
• session.has_full_snapshot = false means the backend never received a replay segment containing a full snapshot
• session.is_replay_available = false follows from that, without a full snapshot, the replay can't be played

These fields come from two different sources: has_replay is set client-side by the SDK on RUM events (which are small and sent frequently), while has_full_snapshot depends on the actual replay segments (which are larger, compressed, and flushed periodically or on some other conditions) reaching our backend.

So the most likely explanation is that the replay segments were lost before being delivered, for example if the page was closed or navigated away before the SDK had time to flush them. This is more likely to happen with sessionReplaySampleRate: 1 + force, because recording starts later in the session (when the user triggers it), leaving less time for segments to be sent compared to sessionReplaySampleRate: 100 where recording starts immediately at init.

That said, could you share more context about how your users trigger startSessionReplayRecording({ force: true })? Specifically:

• How long after page load does the force call typically happen?
• Do users tend to close/navigate away shortly after triggering it?
• Is this happening on a SPA or do users navigate across full page loads?

This would help us confirm whether the timing/delivery explanation holds, or if there's something else going on.
Thanks

[paco-spr]

That said, could you share more context about how your users trigger startSessionReplayRecording({ force: true })? Specifically:

• How long after page load does the force call typically happen?
• Do users tend to close/navigate away shortly after triggering it?
• Is this happening on a SPA or do users navigate across full page loads?

This would help us confirm whether the timing/delivery explanation holds, or if there's something else going on. Thanks

I haven’t enabled this in production yet. I ran into this while evaluating startSessionReplayRecording({ force: true }) ahead of rollout.

This is happening in an SPA. I’ve tested triggering recording at different times after page load, ranging from a few seconds to several minutes, and I’ve also tried waiting for a while after stopping recording. I’ve reproduced the behavior across multiple browsers with ad blockers fully disabled.

What I’m seeing is that sometimes a session seems to get into a broken state, and once that happens, forcing recording for that session never works. I’ve been manually trying to force a fresh session by clearing site data, including third-party cookies, although I realize that may interfere with the SDK’s ability to flush data. Because of that, I usually wait 5 to 15 minutes before clearing anything. If I don’t, the session seems to take a long time to end, even after closing the browser.

[Sacha924]

Thanks for the details,
When your session doesn't have session.is_replay_available:true, do you see requests going to a URL containing /api/v2/replay ? That would tell us whether the issue is data not being sent at all vs not being processed correctly on our end.