Double session count with AutoSessionTracking=true

[TimBurik]

Package

Sentry

.NET Flavor

.NET

.NET Version

10.0.100-preview4

OS

Android

OS Version

No response

Development Environment

Rider 2025 (MacOS)

SDK Version

5.11.2

Self-Hosted Sentry Version

No response

Workload Versions

Workload version: 10.0.100-preview.4.25263.1

Installed Workload Id Manifest Version Installation Source

android 36.0.0-preview.4.80/10.0.100-preview.4 SDK 10.0.100-preview.4
ios 18.4.10471-net10-p4/10.0.100-preview.4 SDK 10.0.100-preview.4
macos 15.4.10471-net10-p4/10.0.100-preview.4 SDK 10.0.100-preview.4
wasm-tools 10.0.100-preview.4.25258.110/10.0.100-preview.4 SDK 10.0.100-preview.4
wasm-tools-net8 10.0.100-preview.4.25258.110/10.0.100-preview.4 SDK 10.0.100-preview.4
wasm-tools-net9 10.0.100-preview.4.25258.110/10.0.100-preview.4 SDK 10.0.100-preview.4

UseSentry or SentrySdk.Init call

SentrySdk.Init(options =>
{
    options.Dsn = "";
    options.Release = "SentryPlayground@1.0.0";
    options.Environment = "debug";
    options.Debug = true;

    options.AutoSessionTracking = true;  // seems to be enabled by default on Mobile platforms
});

Steps to Reproduce

1. Initialize Sentry SDK with AutoSessionTracking=true;
2. Launch the application;
3. Observe the outgoing traffic;

Expected Result

Each Sentry SDK initialization is counted as a single session.

Actual Result

We are using our own tools to monitor application launches. After some time we noticed that the amount of sessions reported by Sentry is more than two times bigger than the amount of launches reported by our tool. After checking the traffic using Charles Proxy we noticed that right after Sentry SDK initialization there are two requests to the api/envelope/ endpoint, for example:

{"sdk":{"name":"sentry.java.android.dotnet","version":"8.6.0","packages":[{"name":"maven:io.sentry:sentry","version":"8.6.0"},{"name":"maven:io.sentry:sentry-android-core","version":"8.6.0"},{"name":"maven:io.sentry:sentry-android-replay","version":"8.6.0"},{"name":"maven:io.sentry:sentry-android-ndk","version":"8.6.0"}],"integrations":["UncaughtExceptionHandler","ShutdownHook","SendCachedEnvelope","Ndk","AppLifecycle","AnrV2","ActivityLifecycle","ActivityBreadcrumbs","CurrentActivity","EnvelopeFileObserver","UserInteraction","AppComponentsBreadcrumbs","SystemEventsBreadcrumbs"]},"sent_at":"2025-07-10T09:14:41.415Z"}
{"content_type":"application/json","type":"session","length":263}
{"sid":"db20ab1a6a024637af647e2252dba6ee","did":"2aa909e2ae2947a19e1a0e1e2cad216a","init":true,"started":"2025-07-10T09:14:41.386Z","status":"ok","errors":0,"timestamp":"2025-07-10T09:14:41.386Z","attrs":{"release":"SentryPlayground@1.0.0","environment":"debug"}}

{"sdk":{"name":"sentry.dotnet","version":"5.11.2"},"sent_at":"2025-07-10T09:14:41.531745 00:00"}
{"type":"session","length":292}
{"sid":"1a453159ddff42618c83c9933ddc5df5","did":"e1e056e9-bb2c-4d65-a271-794af1793512","init":true,"started":"2025-07-10T11:14:41.4554246 02:00","timestamp":"2025-07-10T09:14:41.4605099 00:00","seq":0,"duration":0,"errors":0,"attrs":{"release":"SentryPlayground@1.0.0","environment":"debug"}}

so two sessions with different IDs are reported by different layers of the SDK almost at the same time.

The issue seems to be related to the fact, that AutoSessionTracking=true option is used by the sentry-dotnet SDK itself and also passed to the sentry-java SDK.

Also, it seems that iOS application with AutoSessionTracking=true has the same issue.

[TimBurik]

There seems to be a workaround for this issue:

options.AutoSessionTracking = false;
options.AddIntegration(new AutoSessionTrackingIntegration());

where AutoSessionTrackingIntegration is based on the internal https://github.com/getsentry/sentry-dotnet/blob/main/src/Sentry/Integrations/AutoSessionTrackingIntegration.cs:

class AutoSessionTrackingIntegration : ISdkIntegration
{
    public void Register(IHub hub, SentryOptions options)
    {
        hub.StartSession();
    }
}

[jamescrosswell]

Hm, interesting. Maybe the sentry-dotnet SDK shouldn't propagate the AutoSessionTracking option to the Cocoa/Android SDKs when initialising these.

Edit: Just double checked. This is what the Electron SDK does (wrapping the Node SDK) for exactly this reason... so yes, it looks like this is what we should be doing. That way workarounds like the above would be unecessary.

Thanks for reporting this @TimBurik - we'll get a fix out ASAP!

[TimBurik]

Just one point for consideration though: should the Cocoa/Android SDKs be tracking sessions instead of dotnet SDK?
I haven't check the implementation on their side yet, but if they can handle some more platform-specific cases when it comes to the session tracking - maybe it would be better to use them instead.

[bruno-garcia]

in Unity and I wa shooing we did the same here we track on the dotnet side and on restart if we find a unfinished session we call a function from the native layer: crashedLastSession or something.

This way we know if it crashed due to an event captured via dotnet or via native

Maybe the sentry-dotnet SDK shouldn't propagate the AutoSessionTracking option to the Cocoa/Android SDKs when initialising these.

It should be hard coded false