Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -127,6 +127,38 @@ In `session` mode, this will upload any pending recording data to Sentry. In `bu

Calling `flush()` while Session Replay is stopped will start a new session recording.

## Listening to Lifecycle Events

<AvailableSince version="10.50.0" />

You can listen to replay lifecycle events on the Sentry client to know when recording starts and stops. This is useful for wrapper libraries or custom UIs that need to stay in sync with replay state.

```javascript
const client = Sentry.getClient();

client.on('replayStart', ({ sessionId, recordingMode }) => {
// recordingMode: 'session' | 'buffer'
console.log(`Replay ${sessionId} started in ${recordingMode} mode`);
});

client.on('replayEnd', ({ sessionId, reason }) => {
// reason: 'manual' | 'sessionExpired' | 'sendError' | 'mutationLimit'
// | 'eventBufferError' | 'eventBufferOverflow'
console.log(`Replay ${sessionId} ended: ${reason}`);
Comment on lines +139 to +147
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The documentation for replayStart and replayEnd hooks incorrectly uses sessionId instead of replayId in the payload example, which will be undefined for users.
Severity: MEDIUM

Suggested Fix

Update the documentation to replace sessionId with the correct identifier, replayId, in the code examples for the replayStart and replayEnd lifecycle hooks to match the actual SDK implementation.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
docs/platforms/javascript/common/session-replay/understanding-sessions.mdx#L139-L147

Potential issue: The documentation for the `replayStart` and `replayEnd` lifecycle hooks
incorrectly uses `sessionId` in the event payload examples. The Sentry JS Replay SDK
consistently uses `replayId` for the replay identifier in other contexts, such as
`replay.getReplayId()` and the wire format `replay_id`. Users who follow the
documentation and attempt to destructure `{ sessionId }` from the event payload will
receive `undefined`, causing their implementation to fail silently.

Did we get this right? 👍 / 👎 to inform future reviews.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, sessionId is the right payload value. No replayId is present.

});
```

The `replayEnd` hook includes a typed `reason` so you can distinguish calling `replay.stop()` yourself from an internal stop:

| Reason | Description |
|--------|-------------|
| `manual` | You called `replay.stop()` |
| `sessionExpired` | The session exceeded max duration or idle timeout |
| `sendError` | The SDK failed to send recording data to Sentry |
| `mutationLimit` | The DOM mutation limit was exceeded |
| `eventBufferError` | The event buffer hit an internal error |
| `eventBufferOverflow` | The event buffer exceeded its size limit |

## Examples of Custom Sampling

There are ways to enable custom sampling if you're interested in tracking a particular action or group, for example, a specific segment of users or a problematic URL.
Expand Down
Loading