Skip to content

feat(replay): Add flush method to integration #6776

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 19, 2023
Merged

feat(replay): Add flush method to integration #6776

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
6 changes: 6 additions & 0 deletions packages/replay/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,3 +233,9 @@ However, please note that it is _possible_ that the error count reported on the
does not match the actual errors that have been captured.
The reason for that is that errors _can_ be lost, e.g. a network request fails, or similar.
This should not happen to often, but be aware that it is theoretically possible.

## Manually sending replay data

You can use `replay.flush()` to immediately send all currently captured replay data.
This can be combined with `replaysOnErrorSampleRate: 1`
in order to be able to send the last 60 seconds of replay data on-demand.
11 changes: 11 additions & 0 deletions packages/replay/src/integration.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -185,6 +185,17 @@ Sentry.init({ replaysOnErrorSampleRate: ${errorSampleRate} })`,
this._replay.stop();
}

/**
* Immediately send all pending events.
*/
public flush(): Promise<void> | void {
if (!this._replay || !this._replay.isEnabled()) {
return;
}
Comment on lines +192 to +194
Copy link
Member

Choose a reason for hiding this comment

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

l: Just wondering if we should check for isPaused() here as well... technically, recording could be paused b/c of rate limiting and we wouldn't want to flush in this case. But overall, I think chances are pretty low that this would actually happen. And even if it does, the consequences wouldn't be bad, as we're already handling rate limit responses while being rate-limited. WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I thought the same. I'd say it is OK, as (theoretically) when paused the event buffer has to be empty always, so it wouldn't even attempt to send anything. I'd say it is OK to leave it like this?

Copy link
Member

Choose a reason for hiding this comment

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

when paused the event buffer has to be empty always

Not necessarily, pause just stops DOM recording, we could have events from window.performance, but in that case, might be ok to try to flush.

Copy link
Member Author

Choose a reason for hiding this comment

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

hmm yeah, true, I'd say that is not incorrect to flush the stuff that has not been sent yet due to being paused?


return this._replay.flushImmediate();
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't it better to only allow users to use debounced flush to reduce risk of being flooded with flushes?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, this would kind of defeat the purpose (a bit) of this - as e.g. if a user clicks a button, we trigger debounced flush, the user closes the window --> we may not have sent the stuff yet. IMHO it's OK to put this burden on the SDK users - it's up to them to only use this sparingly?

Copy link
Member

Choose a reason for hiding this comment

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

I'm good with that

}

/** Setup the integration. */
private _setup(): void {
// Client is not available in constructor, so we need to wait until setupOnce
Expand Down