Problem Statement
When using replayIntegration in manual mode, there is no way for external code to know when the replay has stopped due to internal reasons such as maxReplayDuration expiry.
This makes it impossible to keep external state in sync with the actual replay state. For example, a wrapper library that tracks active replay sessions via an activeSession array has no way to know when Sentry has internally stopped the replay — leading to stale state where the wrapper believes recording is still active when it is not.
The problem is not limited to maxReplayDuration. Any internal stop (error budget, rate limiting, idle timeout) has the same issue.
Solution Brainstorm
Add lifecycle event hooks to the Replay integration following the same client.on(event, callback) pattern already established in @sentry/core:
const replay = getReplay();
replay.on('start', () => {
console.log('Replay started');
});
replay.on('stop', ({ reason }) => {
// reason: 'maxDuration' | 'manual' | 'error' | 'inactivity' | ...
console.log('Replay stopped, reason:', reason);
});
The reason field on the stop event would be particularly valuable — it lets consumers distinguish between an intentional manual stop and an internally triggered one, so they can decide whether to restart recording or just update their state.
Additional Context
No response
Priority
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.
Problem Statement
When using
replayIntegrationin manual mode, there is no way for external code to know when the replay has stopped due to internal reasons such asmaxReplayDurationexpiry.This makes it impossible to keep external state in sync with the actual replay state. For example, a wrapper library that tracks active replay sessions via an
activeSessionarray has no way to know when Sentry has internally stopped the replay — leading to stale state where the wrapper believes recording is still active when it is not.The problem is not limited to
maxReplayDuration. Any internal stop (error budget, rate limiting, idle timeout) has the same issue.Solution Brainstorm
Add lifecycle event hooks to the
Replayintegration following the sameclient.on(event, callback)pattern already established in@sentry/core:The
reasonfield on the stop event would be particularly valuable — it lets consumers distinguish between an intentional manual stop and an internally triggered one, so they can decide whether to restart recording or just update their state.Additional Context
No response
Priority
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it.