fix: BackpressureMonitor.Dispose() no longer deadlocks on single-threaded targets

[jamescrosswell]

Fixes #5237

Problem

On single-threaded runtimes (Unity WebGL / browser-wasm) there is no separate thread pool — Task.Run and Task.Delay continuations all run on the one main thread. BackpressureMonitor.Dispose() did:

_cts.Cancel();
_workerTask.Wait();   // blocks the only thread

_workerTask.Wait() synchronously blocks the calling thread waiting for the worker's post-cancellation continuation, which on a single-threaded runtime can only be scheduled on that same blocked thread (e.g. calling unityInstance.Quit() in Unity WebGL).

ConfigureAwait(false) does not help here. On a desktop host the cancellation continuation escapes to a real thread-pool thread. On single-threaded targets the "thread pool" is the main thread, so the continuation has nowhere to run except the thread that is blocked in Wait().

Fix

Dispose() now only requests cancellation and returns — it does not block on the worker. The worker observes the token, exits its Task.Delay loop and unwinds on its own; it produces no result anyone needs to await.

Because the monitor's public methods (DownsampleFactor / RecordQueueOverflow / RecordRateLimitHit) never touch _cts, it is now safe to dispose the monitor even while the client keeps draining envelopes. This lets Hub.Dispose() dispose the monitor again rather than leaking the worker for the process lifetime.

⚠️ Hub.Dispose()

The call to _backpressureMonitor?.Dispose() was removed in #4613 with the comment:

Don't dispose … without throwing an ObjectDisposedException

I've restored it because, with a non-blocking Dispose() that only cancels/disposes the CTS, none of the monitor's post-disposal call sites touch the disposed token source — so the original ObjectDisposedException should not recur.

Warning

TODO: Confirm this matches the scenario #4613 was guarding against. We can always reinstate the fix from #4613 if we're concerned about this.

Affected versions

The live deadlock path (Hub.Dispose() → _backpressureMonitor?.Dispose()) exists in 4.x/5.x (and the Sentry Unity 4.x that reported this). It was incidentally removed on main/6.0.0+ by #4613, so 6.x no longer reaches the deadlock - but at the cost of leaking the worker. Dispose() itself remained latently broken. This PR fixes the root cause so the call is safe again. Users on ≤5.x operating in a single threaded environment should set EnableBackpressureHandling = false as a workaround instead.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 94.11765% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 74.20%. Comparing base (0061920) to head (a56d248).

Files with missing lines	Patch %	Lines
src/Sentry/Internal/BackpressureMonitor.cs	93.75%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5330      +/-   ##
==========================================
+ Coverage   74.16%   74.20%   +0.04%     
==========================================
  Files         508      508              
  Lines       18353    18363      +10     
  Branches     3586     3589       +3     
==========================================
+ Hits        13612    13627      +15     
+ Misses       3869     3864       -5     
  Partials      872      872              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.