Disposing the Hub with AutoSessionTracking gives an error

[lucas-zimerman]

As observed on Unity, when you dispose of a hub and usingAutoSessionTracking, an error will be thrown once the SDK disposes of the SDK hub. You can reproduce the error with the following snippet:

void StartSentry()
{
    SentrySdk.Init(o =>
    {
        o.Dsn = "https://eb18e953812b41c3aeb042e666fd3b5c@o447951.ingest.sentry.io/5428537";
        o.AutoSessionTracking = true;
        o.CacheDirectoryPath = "C:/Users/.../AppData/LocalLow/Sentry/Sentry Defenses/Sentry";
        o.Debug = true;
    });
}
StartSentry();
StartSentry();
Console.ReadKey();

The following error was received:

Error: Failed to send cached envelope: C:/Users/lucas/AppData/LocalLow/Sentry/Sentry Defenses/Sentry\Sentry\132A73C90BBA506000857BC4BFC23E574F1551B5\__processing\1638992610_1647__6590935.envelope, retrying after a delay.
System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at Sentry.Internal.Extensions.StreamExtensions.ReadAllBytesAsync(Stream stream, CancellationToken cancellationToken)+MoveNext() in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Internal\Extensions\StreamExtensions.cs:line 18
   at Sentry.Internal.Extensions.StreamExtensions.ReadAllBytesAsync(Stream stream, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
   at Sentry.Protocol.Envelopes.Envelope.DeserializeHeaderAsync(Stream stream, CancellationToken cancellationToken) in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Envelopes\Envelope.cs:line 188
   at Sentry.Protocol.Envelopes.Envelope.DeserializeHeaderAsync(Stream stream, CancellationToken cancellationToken) in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Envelopes\Envelope.cs:line 188
   at Sentry.Protocol.Envelopes.Envelope.DeserializeAsync(Stream stream, CancellationToken cancellationToken) in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Envelopes\Envelope.cs:line 212
   at Sentry.Internal.Http.CachingTransport.InnerProcessCacheAsync(String envelopeFilePath, CancellationToken cancellationToken) in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Internal\Http\CachingTransport.cs:line 195
   at Sentry.Internal.Http.CachingTransport.InnerProcessCacheAsync(String envelopeFilePath, CancellationToken cancellationToken) in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Internal\Http\CachingTransport.cs:line 207
   at Sentry.Internal.Http.CachingTransport.ProcessCacheAsync(CancellationToken cancellationToken) in D:\Development\Online Projects\Sentry\sentry-dotnet\src\Sentry\Internal\Http\CachingTransport.cs:line 159  Debug: Background worker of CachingTransport has shutdown.

[bruno-garcia]

The SDK is getting Disposed when Init is called again. So the behavior is correct there.
The issue is: Why is it getting Inititalized twice? Init is supposed to be called once in the app lifecycle

[SimonCropp]

Init is supposed to be called once in the app lifecycle

so should we throw on the second init call?

[SimonCropp]

@bruno-garcia @lucas-zimerman thoughts on the above?

[vaind]

so should we throw on the second init call?

That would be breaking though, wouldn't it?

[bruno-garcia]

The SDK should be OK with being disposed without breaking internally though. Once there's "more information" a following Init call is done. That's not ideal but can happen, also when there are more than 1 package and "init" is setup on both. That's not ideal but because it's a bit of a trap that each integration can initialize, it can happen. The static SentrySdk class does an atomic swap between hubs (old to new) so we can flush it and let it go out of scope so GC does it's thing. Since we don't want to Dispose in favor to Flushing only (see #599 ), it's possible finalizer thread will need to clear some unmanaged resources if we happened to allocate one in the previous calls

[mattjohnsonpint]

Closing in favor of #2033