sentry icon indicating copy to clipboard operation
sentry copied to clipboard

Published 20 hours ago • verified publisher icon getsentry

Bug: Timeline recording status overflows when a recording finishes playing

Open billyvg opened this issue 3 years ago • 7 comments

Example replay: https://sentry.io/organizations/sentry/replays/javascript:f928ac21-d6dc-4300-945e-d0f05863ae8a/

Play the recording and when it finishes, the purple "status" bar in the timeline ends up overflowing.

Image

billyvg avatar Aug 18 '22 15:08 billyvg

I think this is a start/finish timestamp issue

  • The replay says: finishedAt = "2022-08-18T14:54:58+00:00" (note: 58th second)
  • The last segment has a timestamp of: dateAdded: "2022-08-18T14:54:59.058074Z" (note: 59th second)

So that segment is appearing 'after' the replay is finished.

ryan953 avatar Aug 18 '22 18:08 ryan953

Related to https://github.com/getsentry/sentry-replay/issues/148

ryan953 avatar Aug 30 '22 23:08 ryan953

@ryan953 Here's one where it looks like finishedAt == last segment but it's overflowing: https://sentry.io/organizations/sentry-emerging-tech/replays/billy-test:a059b6139367467aab10579061436c47/

Maybe because we lose precision with the duration from the replay record? duration is 5, but when inspecting the timeline, the max duration there is ~5118 (ms).

billyvg avatar Sep 01 '22 14:09 billyvg

This should be fixed by https://github.com/getsentry/sentry-replay/pull/169

billyvg avatar Sep 08 '22 17:09 billyvg

Do we believe the above PR fixed this? Can we close?

benvinegar avatar Sep 14 '22 20:09 benvinegar

Going to see if the cause for duplicate segment ids has also fixed this -- I believe there were still instances where this was overflowing.

billyvg avatar Sep 19 '22 17:09 billyvg

https://sentry.io/organizations/sentry/replays/javascript:952bb398d92242afa05a3676afb08443/?referrer=%2Forganizations%2F%3AorgId%2Freplays%2F&t_main=network

billyvg avatar Sep 19 '22 19:09 billyvg

https://sentry.io/organizations/sentry/replays/javascript:4f3fdfe947b1497cb0ce98710bcf5e26/?referrer=%2Forganizations%2F%3AorgId%2Freplays%2F

billyvg avatar Sep 23 '22 20:09 billyvg

This is an issue where the backend is storing the start/finish + duration in seconds (and losing the ms precision), but our UI uses the difference of "min_timestamp(replay_events)" and "max_timestamp(replay_events)" as the duration (ideally they would match). If we rounded, then we would have to round everything to the second as events (the dots on timeline) could end up outside of the timeline.

billyvg avatar Oct 19 '22 16:10 billyvg

I think @ryan953 is going to change the frontend behavior to not use the timestamps that lack ms precision.

billyvg avatar Oct 19 '22 19:10 billyvg

I think this is fixed now by https://github.com/getsentry/sentry/pull/40281

The improvement is inside of static/app/utils/replays/replayReader.tsx, the finishedAt timestamp usually has ms precision, and we're using that to re-calculate the duration. That sets the right-most bounds of the <Timeline> to the correct place so we shouldn't overflow in the way we have before.

ryan953 avatar Oct 21 '22 16:10 ryan953

There are three examples in the thread above that are still available, they're all working great now:

  • Example From Sept 1st (https://github.com/getsentry/sentry/issues/38000#issuecomment-1234378274) Screen Shot 2022-10-21 at 9 02 09 AM

  • Example From Sept 19 (https://github.com/getsentry/sentry/issues/38000#issuecomment-1251423672) Screen Shot 2022-10-21 at 9 02 13 AM

  • Example From Sept 23 (https://github.com/getsentry/sentry/issues/38000#issuecomment-1256646515) Screen Shot 2022-10-21 at 9 02 18 AM

Looks much better, I will close it out now.

ryan953 avatar Oct 21 '22 16:10 ryan953