Skip to content

fix(sessions): Move and flush unfinished previous session on init #4624

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

romtsn
Copy link
Member

@romtsn romtsn commented Aug 8, 2025

📜 Description

  • Previously, we were waiting on previous session flush latch on our background queue when processing ANRs or finalizing previous session for 15 seconds to give it a good chance to be flushed. However, the trigger for the flush was actually a new session start:

    • We start a new session on foreground
    • We see that there's an existing unfinished session
    • We move it to its own file
    • We flush the latch
      However this was not working well for background app starts. Since there's no foreground event, a new session would not be started and we were waiting for 15 seconds for nothing (on a background thread, but still). So this PR addresses it by moving any unfinished session to its own file right away on init (but before any of the integrations are registered, so those that rely on the previous session latch (like ANRs), do not need to wait for it).
  • We also just rename session.json to previous_session.json now, as opposed to ser/deserializing the session multiple times from/into different files

Before (perfetto trace of a background app start)

Google Chrome 2025-08-08 16 14 48

After (perfetto trace of a background app start)

Screenshot 2025-08-08 at 11 14 24

💡 Motivation and Context

Speed up things on our background queue

💚 How did you test it?

Manually + automated

📝 Checklist

  • 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.

🔮 Next steps

@romtsn
Copy link
Member Author

romtsn commented Aug 8, 2025

@markushi I'm unsure about how this affects the Hybrid SDKs, but form a quick look into InternalSentrySdk I don't think anything needs to change. But let me know if there's something I missed.

Comment on lines +440 to +441
final boolean renamed = currentSessionFile.renameTo(previousSessionFile);
if (!renamed) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potential bug: If `renameTo` fails in `movePreviousSession`, a latch is still released, causing `PreviousSessionFinalizer` to proceed and silently lose the session data.
  • Description: The movePreviousSession method in EnvelopeCache attempts to rename the currentSessionFile. If this renameTo() operation fails due to filesystem issues or permissions, it only logs a warning. However, it proceeds to call flushPreviousSession(), which releases the previousSessionLatch. The PreviousSessionFinalizer is dependent on this latch. Once unblocked, it attempts to process the previous session but fails to find the file because the rename operation was unsuccessful. This results in the session data being silently and permanently lost, which can affect the accuracy of analytics and crash reporting.
  • Suggested fix: Check the boolean return value of currentSessionFile.renameTo(previousSessionFile). If the rename operation returns false, do not call flushPreviousSession(). This will prevent the PreviousSessionFinalizer from proceeding prematurely and allow for proper error handling or retry logic for the failed file operation.
    severity: 0.82, confidence: 0.95

Did we get this right? 👍 / 👎 to inform future reviews.

Copy link
Contributor

github-actions bot commented Aug 8, 2025

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 400.64 ms 444.39 ms 43.75 ms
Size 1.58 MiB 2.09 MiB 522.37 KiB

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant