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

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.21%. Comparing base (0061920) to head (35ece53).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5330      +/-   ##
==========================================
+ Coverage   74.16%   74.21%   +0.04%     
==========================================
  Files         508      508              
  Lines       18353    18363      +10     
  Branches     3586     3589       +3     
==========================================
+ Hits        13612    13628      +16     
+ Misses       3869     3863       -6     
  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.

[jamescrosswell]

Should we be passing TaskScheduler.Default here or TaskScheduler.Current? In production it doesn't really matter, since those two things will always be the same. They are only ever different if/when we explicitly pass in a non default scheduler at task creation time... for us, that only happens when running unit tests. So if we used TaskScheduler.Current, I think we'd end up using the Scheduler injected for unit testing purposes here as well (not just when creating the Task above). It probably doesn't really matter since I don't think we have any concurrency problems with this code (it's just disposing of the cts synchronously once the task completes) but for the sake of consistency, maybe it's better to use TaskScheduler.Current here?

[jamescrosswell]

TaskScheduler.Current wouldn't pick up the injected scheduler anyway. Current is evaluated at the point ContinueWith is called — i.e. inside Dispose(), on whatever thread calls it. In the tests Dispose() is invoked from the test thread (or a plain Task.Run), not from within a task running on the injected scheduler, so Current resolves to Default there too. The injected scheduler only governs the worker task's own execution, not this continuation. So Current vs Default makes no observable difference in our tests.