-
-
Notifications
You must be signed in to change notification settings - Fork 234
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
Investigate abnormal sessions on iOS #2169
Comments
@buenaflor Seems to work to me as intended. Was suspecting that 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? |
When is last in foreground written?Tried again when the last in foreground timestamp is written.
In all cases, the Killing the app in multitaskingWhen going to multitasking /**
* 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. |
@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? |
This might happen because of errors originating from platform-specific code, for example SocketException when using http libraries |
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 |
@buenaflor I tried both |
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. |
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:
Then ios sets it as an abnormal session
The text was updated successfully, but these errors were encountered: