Provide a way to programmatically filter replays

[idosun]

Problem Statement

We'd like to have the ability to drop session replays based on dynamic characteristics like:

• User segmentation
• Length of the captured replay
• Other tags (browser name, OS, etc...)

Solution Brainstorm

Something like a beforeSend for errors and a beforeTransactionSend for performance would be ideal.

┆Issue is synchronized with this Jira Improvement by Unito

[lexprk]

this would help us reduce the barrier to enable session replay across the company

[bruno-garcia]

this would help us reduce the barrier to enable session replay across the company

Could you please share some of the use cases where you'd be filtering? This can help us design the hooks you'll need

[lexprk]

would be very helpful: filter by length of replay (don't save replays shorter than X, longer than X),
would be helpful: filter if contains specific errors. custom tags, or url routes

[ryan953]

Related to getsentry/sentry#53257

[bruno-garcia]

Sample Replays by duration

would be very helpful: filter by length of replay (don't save replays shorter than X, longer than X),

We recently added an option called minReplayDuration that controls the min duration. Value in milliseconds, default is 5000 and max is 15000:

• Replay: Allow the user-defined minimum session duration before flushing #8562
• feat(replay): Ensure min/max duration when flushing #8596
• replay: minReplayDuration sentry-docs#7494

It's available on 7.60: https://github.com/getsentry/sentry-javascript/releases/tag/7.60.0
From release notes:

We will not send replays that are <5s long anymore. Additionally, we also added further safeguards to avoid overly long (>1h) replays.
You can optionally configure the min. replay duration (defaults to 5s):

new Replay({
  minReplayDuration: 10000 // in ms - note that this is capped at 15s max!
})

Sample Replays by other conditions

would be helpful: filter if contains specific errors. custom tags, or url routes

If you want to conditionally sample based on the user, you can set a different value depending on the user in question. replaysSessionSampleRate set to 1.0 would make sure that session is sampled. And 0 that plus replaysOnErrorSampleRate would make sure it's not.

Another alternative, is to not use these sample rates, and use the start and stop functions programatically. We document how to programatically start/stop recording, here: docs.sentry.io/platforms/javascript/session-replay/understanding-sessions/#manually-starting-replay

We understand these are less convenient than having more options built-in to the SDK to control which sessions to sample. We'll keep this ticket open to collect my demand and use cases from folks.

[rabbiveesh]

I'd like to present a use case that we have:

We only want to enable session replays for certain pages in our app (we have a small team, and we're gradually upgrading an internal app to a SaaS). I'm having trouble working out how to do it even using the start and stop functions manually.

What I'd like to set up is to have it set to buffering in the event that it's a page we're not actively tracking, and start a full recording if it's a page we are. But I've run into a couple of walls with this approach:

1. I'm digging through the source, but I can't really see how to introspect if I am currently recording, buffering, or stopped
2. Its unclear to me if calling stop while in buffering mode will send the replay, which is not what i want
3. it's unclear to me if i can upgrade buffering into real recording

[mydea]

Hey, thanks for your input! I'll try to help with your questions:

1. You can kind of check if replay is currently on by checking replay.getReplayId(). This will return undefined if replay is not enabled.
   a. There is currently no public API to check if you are buffering or recording. You can check replay._replay.recordingMode === 'buffer', but that's an internal API that may change at any time.
2. Calling replay.stop() will flush only when in session mode, not when in buffer mode.
3. You can call replay.flush({ continueRecording: true }) to flush a buffer session & convert it to a session session.

IMHO you can realise something like you want like this:

function onPageEnter(url) {
  const shouldFullyTrack = shouldTrackWithReplay(url); // check for which pages we care about
  // just guard that replay is enabled - else, it was stopped from somewhere else and we just do nothing
  if (shouldFullyTrack && replay.getReplayId()) {
    replay.flush({ continueRecording: true });
   // if already in session mode, this will simply flush and continue
  }
}

And generally just initialize replay as replaysOnErrorSampleRate: 1.

This way, replay will always be initialized in buffer mode, but you can manually force it to fully capture it when a user enters a given page.

[mydea]

Hey!

In 7.78.0, you can now configure a callback to replay to solve some further use cases. With beforeErrorSample you can configure to not error-sample for some error events. For example, if you do not want to capture a replay for warning events, you can do:

new Replay({
  beforeErrorSampling(event) {
    return !event.message?.includes('no replay')';
  }
})

This callback receives the fully processed error event. Returning false from this function means that error sampling will not happen for this error, returning true means that we will sample for this error to decide if a replay should be sent.

[bruno-garcia]

Since this is resolved I'll close it. Feel free to reopen if somehow this doesn't resolve ur problem

[rabbiveesh]

@bruno-garcia the latest update only covered errors, the OP (and my question too) was about regular replays too (like tracking only core pages in your app, etc). Given that, i think this is not quite resolved yet

[bruno-garcia]

I see. To be fair I believe that use case is covered with the API we offer for starting/stopping the replay:

https://docs.sentry.io/platforms/javascript/session-replay/understanding-sessions/#manually-starting-replay

You could have onError sample rate (and use the callback to filter depending on error). And additionally depending on a page you load or other condition, programatically starting a reply.

We're probably not adding another callback I imagine correct @mydea @billyvg ? If so, should we close with the solution mentioned above?

[mydea]

Any other callback would be tricky, because we can't really have e.g. beforeSendReplay because this would receive the compressed (?) event data to be sent, or something like this - there is no clear thing to check on there. You can also not really drop a replay after it has flushed already, so you always need to segment before you flush the first time. I think the examples like here: https://docs.sentry.io/platforms/javascript/session-replay/understanding-sessions/#replays-for-specific-users are the best solution for this, and this should be reasonably easy to do now!

[bruno-garcia]

Agreed.

I think the examples like here: docs.sentry.io/platforms/javascript/session-replay/understanding-sessions/#replays-for-specific-users are the best solution for this, and this should be reasonably easy to do now!

Closing with this ^

It's unblocked since it can be achieved with the API but we won't add another hook given the clarifications/complexities @mydea mentioned