Event data consistency for recovered sessions

[espenrl]

The context for this is a MAUI app running on Android.

When an app hard crash, and thus don't have the time needed to report to the Sentry server, instead the information is persisted to file system and sent on the next startup. As I understand it.

sentry-dotnet/src/Sentry/Internal/Hub.cs

Lines 267 to 281 in 8298362

	if (Interlocked.Exchange(ref _isPersistedSessionRecovered, 1) != 1)
	{
	try
	{
	var recoveredSessionUpdate = _sessionManager.TryRecoverPersistedSession();
	if (recoveredSessionUpdate is not null)
	{
	CaptureSession(recoveredSessionUpdate);
	}
	}
	catch (Exception ex)
	{
	_options.LogError(ex, "Failed to recover persisted session.");
	}
	}

When I look at these kind of events (logged to our Sentry Cloud subscription) I get the feeling that the stacktrace is from the previous crashed session, but the breadcrumbs and many other details are from the new session. For example is Start Time always just a few seconds before the event itself. That would align with the event being sent on startup.

My questions is if I'm understanding this correctly. Is the data in the event a mix of both the previous crashed session and the new session?

[jamescrosswell]

@espenrl I can't see how that could happen no. When the event gets written during the terminal error an envelope is created that includes both the exception details (stack trace etc) and the breadcrumbs.

When the app runs again and checks if there were any events recorded (but not able to be sent) it simply checks if there are any envelopes present on the file system and, if so, sends these. Once an envelope has been created there's no more processing done on this so you can consider it's contents at that point immutable (mostly). It can be serialised or deserialised but not changed.

The only small exception to this is that the length of any attachments may sometimes be recomputed... but certainly the breadcrumbs should not change.

[espenrl]

I guess it's related to #3461 . Closing this one.