The comment on line 368-369 states that _manualTransactionOnScope should be 'cleared on the next navigation so we re-evaluate', but the code never sets this flag back to false. Once a user's manual transaction is detected, _manualTransactionOnScope remains true permanently for the singleton MauiEventsBinder, causing all subsequent navigation events to skip creating auto-transactions even after the user's transaction has finished. This contradicts the stated design intent.

The line _activeSpanCount = 0 (guard against underflow) is a non-atomic assignment that can race with Interlocked.Increment in AddChildSpan. If a new span starts between the Interlocked.Decrement and this reset, its increment will be clobbered, causing the idle timer to restart prematurely or the counter to become inconsistent. This can lead to the idle timer firing while spans are still in flight, resulting in premature transaction completion.

The comment on lines 368-369 states '_manualTransactionOnScope' should be 'cleared on the next navigation so we re-evaluate', but the flag is never actually reset to false after being set to true. Once a user-created transaction is detected on the scope, the SDK will permanently stop creating automatic navigation transactions for the lifetime of the MauiEventsBinder instance, even after the user's transaction finishes.

Also found at:

• src/Sentry/SpanTracer.cs:159
• src/Sentry/TransactionTracer.cs:343

The ResetIdleTimeout() method checks !_hasFinished before calling _idleTimer?.Start(), but these operations are not atomic. If Finish() is called concurrently (e.g., when the idle timeout fires on a ThreadPool thread while a UI event is calling ResetIdleTimeout()), the timer can be disposed between the check and the Start() call, causing System.Threading.Timer.Change() to throw ObjectDisposedException. This could crash the application or cause navigation transactions to be lost.