[romtsn]

📜 Description

Touch events and breadcrumbs that happen right after a segment is cut are no longer dropped.

A segment's video duration is rounded up to whole frames, so its end (start + video duration) can be up to one frame interval (1 s at 1 fps) after the time the segment was actually cut. That happens when a segment is cut at an arbitrary time: buffer → session conversion (error capture or flush() in buffer mode), flush() in session mode, and configuration changes. The next segment started at that rounded end for its video and its events, so events between the real cut and the rounded end were in neither segment. On devices this mostly hits touch events after a buffered replay is converted: they go to the session strategy, whose first segment only took events from the rounded end.

Segments now have an event window separate from the video window:

• a cut segment takes breadcrumbs and events up to the cut time (requestedAt in session mode, now in buffer mode) instead of its rounded video end;
• the next segment takes them from that cut time (eventsStartTimestamp), so event windows are back to back with no gap and no overlap;
• video timestamps and durations do not change, and natural 5 s session boundaries stay exact.

Why not shift the video instead: the replay player (videoReplayer.tsx) runs a timer and chains videos on ended. It waits on gaps but does not resync on overlaps, so starting the next video at the cut time would leave the video up to 1 s behind the timeline. Events are merged across segments and placed by their own timestamps (replayReader.tsx), so an event slightly before its segment's video start is shown at the right time.

The detekt baseline changes only re-key existing entries for createSegment, buildReplay and createSegmentInternal, whose signatures gained the two optional parameters.

💡 Motivation and Context

Found while verifying #6340: frames and events between a flush and the rounded end of the flushed segment did not show up in the replay.

💚 How did you test it?

New tests in SessionCaptureStrategyTest and BufferCaptureStrategyTest cover a breadcrumb after a flush landing in the next segment exactly once, and a buffered segment leaving breadcrumbs after its cut to the next segment. Two of them fail without the fix (the third pins the new placement).

On an API 34 emulator with the sample app and a local mock ingest server: startBuffering(), flush() after 5 s, then a navigation breadcrumb and a tap 150 ms after the flush, a control tap 2.5 s after the flush, and stop() after 6 s.

	Segment 0	Segment 1
main	gap breadcrumb, 0 touch events	2 touch events (control tap only) — the gap tap is lost
This PR (2 runs)	nothing from the gap	gap breadcrumb, 4 touch events (both taps)

Video sizes were identical between main and this PR.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

🤖 Generated with Claude Code

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.61.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[romtsn]

Closing: the loss is limited to touch events within one frame interval after a segment cut (breadcrumbs usually still land in the cut segment because encoding is slower than the gap), which we decided is acceptable for now. The analysis and the emulator results in the description stay here for reference.