GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — fix(replay): Preserve segment ID after buffer-to-session conversion by romtsn · Pull Request #5753 · getsentry/sentry-java Conversation
Contributor
📜 DescriptionAfter a buffer-to-session conversion ( This created a duplicate segment 0 with a late timestamp that overwrote the original segment 0 from the buffer flush, effectively losing the first segment of the replay. The fix adds a persisted 💡 Motivation and ContextCustomers reported the first segment of error-triggered replays sometimes being missing or showing content from the wrong time range. This was caused by 💚 How did you test it?
📝 Checklist
🔮 Next steps
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
After a buffer-to-session conversion, the replay type stays BUFFER but the segment counter reflects the real sequence. If the app crashes and finalizePreviousReplay recovers the last segment, fromDisk() was normalizing the segment ID to 0 for all BUFFER replays, creating a duplicate segment 0 that overwrites the original. Add a persisted isFlushed flag set when the buffer is successfully flushed. fromDisk() now only normalizes to 0 when the buffer was never flushed (no segments were ever sent to the server). Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
|
There was an error while loading. Please reload this page.
📲 Install BuildsAndroid
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 6b019b7 | 319.84 ms | 333.15 ms | 13.31 ms |
| eb95ded | 317.51 ms | 369.08 ms | 51.57 ms |
| 319f256 | 317.53 ms | 370.83 ms | 53.29 ms |
| b3d8889 | 420.46 ms | 453.71 ms | 33.26 ms |
| 6b019b7 | 403.90 ms | 546.09 ms | 142.19 ms |
| 889ecea | 367.58 ms | 437.52 ms | 69.94 ms |
| d15471f | 303.49 ms | 439.08 ms | 135.59 ms |
| d364ace | 384.53 ms | 453.51 ms | 68.98 ms |
| 6ea4329 | 309.06 ms | 353.48 ms | 44.42 ms |
| c8125f3 | 383.82 ms | 441.66 ms | 57.84 ms |
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 6b019b7 | 0 B | 0 B | 0 B |
| eb95ded | 0 B | 0 B | 0 B |
| 319f256 | 1.58 MiB | 2.19 MiB | 619.79 KiB |
| b3d8889 | 1.58 MiB | 2.10 MiB | 535.07 KiB |
| 6b019b7 | 0 B | 0 B | 0 B |
| 889ecea | 1.58 MiB | 2.11 MiB | 539.75 KiB |
| d15471f | 1.58 MiB | 2.13 MiB | 559.54 KiB |
| d364ace | 1.58 MiB | 2.11 MiB | 539.75 KiB |
| 6ea4329 | 1.58 MiB | 2.29 MiB | 719.82 KiB |
| c8125f3 | 1.58 MiB | 2.10 MiB | 532.32 KiB |
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 39e4c55 | 352.43 ms | 446.94 ms | 94.51 ms |
| 048e40b | 322.47 ms | 362.69 ms | 40.22 ms |
| 94ec28b | 317.49 ms | 407.84 ms | 90.35 ms |
| a5d4b7b | 413.28 ms | 506.54 ms | 93.26 ms |
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| 39e4c55 | 0 B | 0 B | 0 B |
| 048e40b | 0 B | 0 B | 0 B |
| 94ec28b | 0 B | 0 B | 0 B |
| a5d4b7b | 0 B | 0 B | 0 B |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
There was an error while loading. Please reload this page.
After buffer-to-session conversion, use the persisted segmentTimestamp (which chains with previous segments) instead of the first frame timestamp, avoiding gaps in the recovered segment timeline. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
The gap from using first-frame timestamp vs persisted segmentTimestamp is at most ~1s (1/frameRate) — negligible for crash recovery. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0f4db61. Configure here.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.