MAUI/iOS - Spans recorded to wrong transaction when creating multiple transactions simultaneously

[MichaelLHerman]

Package

Sentry

.NET Flavor

.NET

.NET Version

8.0

OS

iOS

SDK Version

4.10.1

Self-Hosted Sentry Version

No response

Steps to Reproduce

I am trying to migrate a .NET Maui app from AppCenter to Sentry. We were using AppCenter's Event logging extensively for analytics. I am trying to replace that with spans and breadcrumbs but I'm running into issues regarding global scope.

The app is offline capable, so it saves changes in a database and has a "sync queue" to make service calls if online, retry if unsuccessful, etc.

I'm instrumenting both user actions (button clicks) and the sync queue work for analytics and troubleshooting. To do so, I create transactions around every ICommand implementation and every run of the sync queue. Since I don't want to modify my whole codebase passing transactions/scopes to the service layer (for event logging), or database and api layer (for span creation), I am relying on setting the Scope's Transaction for the data layer to create its child spans. I'm using SentryHttpMessageHander to generate spans for api calls, which also relies on the Scopes Transaction.

Since both UI actions and background work happen at the same time, they override the current Scope Transaction and spans and breadcrumbs get logged to the wrong transaction, losing important data.

Reproducible Sample

1. Clone demonstration https://github.com/MichaelLHerman/SentryMobileScope, change Sentry Dsn
2. Run app targeting iOS simulator
3. Click "Click Me" button several times in rapid succession
4. Observe in Sentry that "remove" and "get" spans are being logged under the "test.ui.command" "click" transaction. "get" and "remove" are only being logged by the sync queue, they should only appear under the "send" transaction. "click" should only have "save"'s.

Expected Result

I think client apps need a way to have Global Scope turned off.

I'd like guidance on how to turn IsGlobalModeEnabled to false. I tried doing so and tried surrounding each transaction in a _hub.PushScope() / .Dispose() but from inspecting the variables in the debugger, it appeared that the Scope stack was not getting popped on dispose and was continuously increasing.

Actual Result

[jamescrosswell]

Thanks for the sample app @MichaelLHerman - I can easily reproduce this.

The question is now what to do about it 😄

[jamescrosswell]

@MichaelLHerman currently you have a single instance of DataService/Database shared between MainPage and the WorkQueue:

MainUIThread  ➙ MainPage  ➘
                    DataService ➙ DataBase
ThreadPool    ➙ WorkQueue ➚

Essentially you want spans created by the DataService/DataBase to be children of either the transaction created by the MainPage or the WorkQueue... depending on which one is calling the DataService/DataBase method.

I wondered if the active thread could be used to determine this. However, you could end up on the thread pool from async/await calls from either the MainPage or the WorkQueue, so I don't think this works. You could infer the calling context from a stack trace, but that would be extremely expensive so, again, not a great option.

As such, I think there are only two ways to achieve what you want:

1. Either you create separate instances of DataService/Database and provide each service with enough information to be able to determine its calling context
2. Or you pass the calling context to every method that you use from the DataService/Database

Of the two approaches, the cleanest seems to be option number 1. I did a bit of hacking around to create a variant of the repository that you shared to get something like the isolation you're after. It's not very clean... it could be tidied up with the use of Interfaces and dependency injection, but as a POC I think it works:

• https://github.com/jamescrosswell/SentryMobileScope

[MichaelLHerman]

@jamescrosswell
Thanks for the sample - definitely very helpful and I'll dive more into it tomorrow how I could create a "Dual"ton pattern for IsolatedTransactionManager and pass that into Transient/PerInstance "Service"s, but I'm sure I'll get pushback from my team on making too many changes to the app.

I also don't think the IsolatedTransaction idea would work with SentryHttpMessageHandler, which has the same problem - apis are called from both Commands/ViewModels and from the work queue (both through Service Layer -> Api Layer -> Api Call) and its implementation uses _hub.GetSpan. Would need custom implementation.

I wondered if the active thread could be used to determine this. However, you could end up on the thread pool from async/await calls from either the MainPage or the WorkQueue, so I don't think this works.

The UI thread has thread-affinity where all awaits will return to the UI thread and (at least right now in my app) the work queue is currently always single-threaded on a task pool thread (but could change to parallelized in the future). Wondering how does this work in ASP.NET's usage of Sentry with IsGlobalModeEnabled=false? I thought Sentry's use of AsyncLocal was for this exact problem - isolated scopes for multiple requests at once. I'll provide a sample branch tomorrow of what I tried on that route.

[jamescrosswell]

I'm sure I'll get pushback from my team on making too many changes to the app

I think that's fair. It gives a flavour for some things you can do with Sentry's lower level API concepts but I'm not sure how well this would scale and I'm not sure I'd recommend using it in a complex/production app.

Disabling GlobalMode

Wondering how does this work in ASP.NET's usage of Sentry with IsGlobalModeEnabled=false? I thought Sentry's use of AsyncLocal was for this exact problem - isolated scopes for multiple requests at once.

It is yes. That used to be the only mode that Sentry supported actually. IsGlobalModeEnabled=true was introduced because of issues using an AsyncLocalScopeStackContainer with GUI apps:

• Make Scope data global on desktop and mobile #628

If you disable Global mode in a MAUI app then you expose yourself to those issues. You might not encounter these initially but if/when you do, there's no easy workaround.

Alternative Solution - OpenTelemetry

I played around with a completely different approach, which is to use Sentry's OpenTelemetry integration and to use OpenTelemetry instrumentation for all the tracing:

• https://github.com/jamescrosswell/SentryMobileScope/tree/otel

I think it's much cleaner than the bespoke isolated scope management I shared earlier.