You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit faef0d5
Browse filesBrowse the repository at this point in the historyBrowse files
fix(replay): Measure recording deadlines on a monotonic clock (JAVA-575)
Session Replay derives every interval from the wall clock. Two of those
intervals are pure control flow, and a clock step corrupts both:
- The 1h `sessionDuration` cap was `frameTimestamp - replayStartTimestamp`.
A forward step past the cap kills a healthy recording on the next frame;
a backward step lets one run indefinitely.
- The 50ms ACTION_MOVE debounce was `lastCapturedMoveEvent + 50 > now`.
A backward step suppresses every move event until the wall clock catches
back up.
Both now use `io.sentry.time.Deadline` on the options' `MonotonicTicker`,
which is `SystemClock.elapsedRealtimeNanos()` on Android. That clock
advances across device suspend just as the wall clock does, so the
conversion preserves today's semantics and only removes the step.
The cap is still evaluated when a frame is captured rather than when its
queued task runs, so a busy replay executor cannot trip it.
Everything else JAVA-575 lists — segment timestamps and durations, frame
filenames, buffer cutoffs, gesture `timeOffset`s — stays on the wall clock:
those values are serialized, and fixing them means re-basing them onto an
`AnchoredClock`, which is a v9 change. `// TODO [MAJOR]` markers record that
at both `ICurrentDateProvider` injection sites.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments