Investigate abnormal sessions on iOS

[buenaflor]

Description

There seems to be a disproportionate amount of abnormal sessions on iOS on certain users compared to Android

Read more about abnormal sessions here

Info

https://github.com/getsentry/sentry-cocoa/blob/e773cad622b86735f1673368414009475e4119fd/Sources/Sentry/SentryHub.m#L177

https://github.com/getsentry/sentry-cocoa/blob/main/Sources/Sentry/SentrySessionTracker.m#L119

This is the code path for setting abnormal sessions.

I can reproduce it by forcibly killing the app through the IDE but I'm struggling to reproduce it from a user's perspective purely through the simulator.

essentially if this is null:

    NSDate *_Nullable lastInForeground =
        [[[hub getClient] fileManager] readTimestampLastInForeground];

Then ios sets it as an abnormal session

[denrase]

@buenaflor Seems to work to me as intended. Was suspecting that willResignActive was not always called, but we are using it correctly with the notification. https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622950-applicationwillresignactive

How large is the gap between iOS/Android? Users on iOS tend to kill apps periodically in multitasking, maybe this could have a negative impact?

[denrase]

When is last in foreground written?

Tried again when the last in foreground timestamp is written.

• Phone is locked
• Entering multitasking
• Going to the home screen

In all cases, the UIApplicationWillResignActiveNotification is received by the SDK and we set the timestamp. So this is correct.

Killing the app in multitasking

When going to multitasking willResignActive is called. After killing the app, willTerminate is called. Which ends the current session and deletes the current timestamp.

/**
 * We always end the session when the app is terminated.
 */
- (void)willTerminate
{
    NSDate *sessionEnded = nil == self.lastInForeground
        ? [SentryDependencyContainer.sharedInstance.dateProvider date]
        : self.lastInForeground;
    SentryHub *hub = [SentrySDK currentHub];
    [hub endSessionWithTimestamp:sessionEnded];
    [[[hub getClient] fileManager] deleteTimestampLastInForeground];
    self.wasDidBecomeActiveCalled = NO;
}

So when restarting we do not have a timestamp, but also no session. This is correct.

Per Apples documentation, we have about 5 seconds to do some final cleanup here. Only issue I could see is we manage to delete the timestamp, but not the session, wich seems very unlikely, as we delete the timestamp after the session.

[denrase]

@buenaflor Tried again and checked apple docs, but i don't see a normal user path wehre this might happen. So I just put this in 'Needs More Information'. Do we have some instances with breadcrumbs so we could figure out if this is an issue?

If not, i'd suggest closing this and re-opening when this gets reported again. WDYT?

[buenaflor]

This might happen because of errors originating from platform-specific code, for example SocketException when using http libraries

[buenaflor]

haven't found much info whether it happens on http or dio but I don't think it would affect the result, best to check both

[denrase]

@buenaflor I tried both dio and http with our sample app an network link conditioner set to 100% loss, but could not provoke any abnormal sessions.

[denrase]

Works as expected when provoking a crash on the plugin side. The session is detected as crashed on the next start, the cached session deleted, crash reported.