Skip to content

Session Replay drives interval/window math from the wall clock #5578

Description

@runningcode

Audit finding B3 — actual bug, MEDIUM (manifests when the clock steps mid-recording).

Epoch is required for RRWeb payload timestamps (that part is correct), but the same wall values also drive windows/durations:

  • Segment durations and the 1h max-session deadline are now - startEpoch diffs — sentry-android-replay/src/main/java/io/sentry/android/replay/capture/SessionCaptureStrategy.kt:107 (segment) and :127 (session duration).
  • BufferCaptureStrategy trim-to-last-30s and ReplayCache.createVideoOf iterate epoch-millis windows; frame files are named by epoch millis.
  • ReplayGestureConverter.kt: timeOffset = now - touchMoveBaseline.

A backward step mid-recording → frames "newer than now": trim can wipe valid frames, segment windows miss/duplicate frames, gesture offsets go negative. A forward step → premature 1h cutoff. NTP/carrier/user steps on phones are realistic.

Source: JAVA-557 §B3.

Metadata

Metadata

Assignees

No one assigned
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions