getsentry/sentry-replay

`replay_start_timestamp` and `timestamp` on segment 0 have large deltas between them

JoshFerge opened this issue · 4 comments

i assume that replay_start_time and timestamp on segment 0 of a replay should be extremely close to eachother (within 20 seconds). we have loads of replays where this is not the case. need to determine why. (linked data in slack)

Related to #216 -- which is one instance of this I've found. Let's keep this ticket open in case there are others.

So still seeing some junk data (from Sentry replays, it comes from img/script assets, mostly from pendo). It's an existing tab whose session has expired. The new events that come in (e.g. user click, api requests) have the correct timestamp, but the "junk" data is from when the tab was last focused (e.g. days ago). This is then used as the new replay's start timestamp and causes duration to be incorrect.

Another case I've seen is that I believe a tab has partially loaded (all of the assets are loaded) but not focused (maybe when chrome has restarted and a tab isn't focused yet), then they later click on the tab and all of the api requests fire.

hmm maybe we can filter out obviously-in-the-past events? like maybe add a 30 minute cutoff from the current time or something?

This should be resolved by #271 (released in 0.6.10)