getsentry / getsentry/sentry-java
Session Replay drives interval/window math from the wall clock
- 主要言語
- Kotlin
- スター
- 1.4k
- フォーク
- 478
- 平均マージ
- 2日 23時間
- マージ済み PR（30日）
- 67
説明
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.
コントリビューションガイド
評価
この issue はまだ評価されていません。