Add a before hook to session replay

[aellett]

Problem Statement

I occasionally use beforeSend to do some extra processing of events before they get sent to Sentry, and I'd like to have a similar capability around session replay. For example, I might want to have an allow-list of certain (user) identifiers or features that should allow a replay to be sent. At the same time, any replay associated with a user/transaction that isn't on that allow-list should be discarded at the client level.

Solution Brainstorm

I thought that this might already exist in the beforeSend hook, but when I examined the event available in that block, it didn't seem like I had an API to access any potential replays. It's possible that I missed it or that it's private, but that was the first place I looked.

I also looked at some of the other beforeXXX hooks, and I saw there was one for beforeCaptureScreenshot and beforeCaptureViewHierarchy, so for consistency I thought it wouldn't be unreasonable to have a beforeSendSessionReplay or beforeCaptureSessionReplay. Obviously those are two different ideas, but I think I could use either of them to get what I'm looking for.

Are you willing to submit a PR?

No response

[philipphofmann]

@aellett, for your info, SentryReplayEvent goes through beforeSend because they are a subclass of SentryEvent, but it's private. You can call serialize to inspects it's contents, but it doesn't contain much info as the recording isn't part of the SentryReplayEvent. We will work on a proper beforeHook, but we can't give you an ETA yet.

[aellett]

Cool, thanks for pointing that out. Might take a look at that to see if there's anything I can work with there. Is it safe to assume that if I receive a SentryReplayEvent in beforeSend and then return nil that it's going to be dropped in the same way that an error or a transaction might be dropped?

[philipphofmann]

Is it safe to assume that if I receive a SentryReplayEvent in beforeSend and then return nil that it's going to be dropped in the same way that an error or a transaction might be dropped?

Yes, that assumption is safe and we would only change that in a major update.