Skip to content

Discard UI event transactions without child spans

09760b3
Select commit
Loading
Failed to load commit list.
Draft

feat: Auto-create traces for MAUI navigation events #5111

Discard UI event transactions without child spans
09760b3
Select commit
Loading
Failed to load commit list.
@sentry/warden / warden: find-bugs completed Apr 7, 2026 in 8m 51s

2 issues

find-bugs: Found 2 issues (2 medium)

Medium

_manualTransactionOnScope flag is never cleared, permanently disabling auto navigation transactions - `src/Sentry.Maui/Internal/MauiEventsBinder.cs:338-341`

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
Race condition in ResetIdleTimeout can cause ObjectDisposedException - `src/Sentry/TransactionTracer.cs:397-402`

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.


Duration: 8m 45s · Tokens: 8.6M in / 83.6k out · Cost: $12.28 (+extraction: $0.01, +merge: $0.00, +fix_gate: $0.00)

Annotations

Check warning on line 341 in src/Sentry.Maui/Internal/MauiEventsBinder.cs

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: find-bugs

_manualTransactionOnScope flag is never cleared, permanently disabling auto navigation transactions

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.

Check warning on line 159 in src/Sentry/SpanTracer.cs

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: find-bugs

[GPX-WHB] _manualTransactionOnScope flag is never cleared, permanently disabling auto navigation transactions (additional location)

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.

Check warning on line 343 in src/Sentry/TransactionTracer.cs

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: find-bugs

[GPX-WHB] _manualTransactionOnScope flag is never cleared, permanently disabling auto navigation transactions (additional location)

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.

Check warning on line 402 in src/Sentry/TransactionTracer.cs

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: find-bugs

Race condition in ResetIdleTimeout can cause ObjectDisposedException

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.