-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(replay): Ignore old events when manually starting replay #12349
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.
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
Conversation
size-limit report 📦
|
What happens if there is a sample rate and the user calls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot simpler fix than I figured, amaze!
Co-authored-by: Catherine Lee <55311782+c298lee@users.noreply.github.com>
If you call |
This PR ensures that if a replay is manually started (=no sample rates are defined at all, and a user later calls `start()` or `startBuffering()`, we do not back-port the `initialTimestamp` of the replay based on the event buffer. By default (for the first segment) we'll backport the `initialTimestamp` to the time of the first event in the event buffer, to ensure that e.g. the pageload browser metrics that may be emitted with an earlier timestamp all show up correctly. However, this may be unexpected if manually calling `startBuffering()` and seeing things for stuff that happened before. Now, we keep track of this and adjust the behavior accordingly. Fixes #11984 --------- Co-authored-by: Catherine Lee <55311782+c298lee@users.noreply.github.com>
This PR ensures that if a replay is manually started (=no sample rates are defined at all, and a user later calls
start()
orstartBuffering()
, we do not back-port theinitialTimestamp
of the replay based on the event buffer.By default (for the first segment) we'll backport the
initialTimestamp
to the time of the first event in the event buffer, to ensure that e.g. the pageload browser metrics that may be emitted with an earlier timestamp all show up correctly.However, this may be unexpected if manually calling
startBuffering()
and seeing things for stuff that happened before.Now, we keep track of this and adjust the behavior accordingly.
Fixes #11984