Fix PT Run ThreadPool worker leak from stale query cancellation

[crutkas]

Summary

Fixes a ThreadPool worker leak in PT Run that, given enough time and rapid typing, manifests as System.OutOfMemoryException raised by Thread.StartInternal (i.e., the OS refuses to give PT Run another worker thread).

Related: open issue #36041, plus auto-closed dupes #45704, #36587, #39942, #20264, #8878.

What was happening

MainViewModel.QueryResults cancels the previous in-flight query by replacing the _updateToken CancellationToken field with a fresh token on every keystroke:

_updateSource?.Cancel();
_updateSource?.Dispose();                       // (1) racy
var currentUpdateSource = new CancellationTokenSource();
_updateSource = currentUpdateSource;
_updateToken = _updateSource.Token;             // (2) field swap

Every ThrowIfCancellationRequested() call inside the running Task.Factory.StartNew body and the two Parallel.ForEach calls then reads the field _updateToken at runtime. After the next keystroke replaces the field with a new (non-cancelled) token, the previous task observes the new token and never cancels. It runs every plugin to completion, fans out across Parallel.ForEach, and the worker threads it requested are never returned to a usable state until that work finishes.

Compounding this:

• _updateSource.Dispose() is called immediately after Cancel(), racing with in-flight consumers; they can hit ObjectDisposedException (which the surrounding catch (OperationCanceledException) does not handle) instead of OperationCanceledException.
• Neither Parallel.ForEach is passed ParallelOptions { CancellationToken = ... }, so iterations can't stop between items even when the token is honored.
• Task.Factory.StartNew / ContinueWhenAll were not given an explicit TaskScheduler, picking up TaskScheduler.Current which can be the UI scheduler in some call paths.

Over time the leaked work saturates the ThreadPool's worker creation budget and PT Run dies with E_OUTOFMEMORY raised by Thread.StartInternal (which has no managed frames yet, so the throw site shows up as unknown_function in crash reports — which is why this has been hard to root-cause from telemetry alone).

What this PR does

1. Captures the new token into a local updateToken and uses that local inside the Task lambda and both Parallel.ForEach calls. Field reassignment can no longer silently mask cancellation.
2. Defers Dispose of the previous CancellationTokenSource via ContinueWith on the previous query task (tracked via a new _currentQueryTask field), so in-flight consumers can finish observing cancellation before the source is disposed.
3. Passes the token to Parallel.ForEach via ParallelOptions, so the loop stops scheduling new iterations as soon as cancellation is requested.
4. Pins the scheduler to TaskScheduler.Default on StartNew and ContinueWhenAll (avoids the TaskScheduler.Current footgun).

The _updateToken field is still updated for RegisterResultsUpdatedEvent consumers, which intentionally want the current token (so stale plugin updates don't pile up).

Why no new unit test

MainViewModel is not currently constructible in Wox.Test (constructor needs settings, plugins, dispatcher, ThemeManager); the existing tests cover static helpers only. A regression test would require non-trivial new test infrastructure — happy to do that in a follow-up if reviewers want it. The change is small and the failure mode is described above with a clear path from cause to crash.

Validation

• Syntactically validated with Roslyn (no diagnostics).
• Local managed build blocked on a pre-existing CppWinRT NuGet restore issue unrelated to this change; relying on CI for full build verification.

Risk

Low. The change is local to MainViewModel.QueryResults. Behavior on the happy path is identical (queries still run, results still update). The observable change is that cancellation actually happens, freeing pool threads as intended.

[crutkas]

@copilot fix the spellbot error. betting as simple as adding a comma to "Otherwise" so it becomes "Otherwise,"

[yeelam-gordon]

Pushed 2eb9fab33d to this branch (maintainer-can-modify) building on top of your fix. Summary of what changed and why, plus the new tests.

What this commit adds on top of yours

Your local-capture fix (var updateToken = currentUpdateSource.Token) is the right root-cause fix for #36041 and is preserved verbatim. The follow-up addresses residual issues from review:

#	Change	Why
1	New internal sealed QuerySession owns one CTS + the tail Task it spawns. Construct via QuerySession.Start(pipelineFactory); post-construction surface is terminal idempotent ops only (Cancel / DisposeWhenComplete / CancelAndWait / Dispose).	SRP. The captured-Token snapshot is now a structural property of the type, so the field-reassignment bug at the root of #36041 can't be reintroduced by any caller that uses session.Token. No mutator surface → no lifecycle race → no lock needed.
2	Task.Run(...) instead of Task.Factory.StartNew(action, token, TaskCreationOptions.None, TaskScheduler.Default)	Task.Run is documented as StartNew(action, CancellationToken.None, DenyChildAttach, Default). Adding DenyChildAttach prevents plugin-spawned attached child tasks from extending the parent's lifetime past cancellation — same leak family the PR is fixing.
3	DenyChildAttach on the doFinalSort ContinueWith. The continuation is composed inside the pipeline factory so it's part of the session's Completion and the previous CTS is not disposed while final sort is still in flight.	Same reasoning as #2; without this the final-sort path could hold workers past cancellation.
4	Removed TaskContinuationOptions.ExecuteSynchronously from the QueryResults ContinueWith.	Per docs: only short-running continuations should run synchronously. If the antecedent had already completed when ContinueWith was created (rare but possible on a fast plugin), the continuation would run on the UI thread.
5	QueryHistory and RegisterResultsUpdatedEvent now snapshot _currentSession?.Token into a local before any async work.	These paths previously read the field; same class of bug as the main one, just in adjacent code.
6	MainViewModel.Dispose now calls _currentSession?.CancelAndWait(TimeSpan.FromSeconds(2)).	App-shutdown path was leaking the in-flight CTS.
7	Corrected the inline rationale comment.	CancellationToken.ThrowIfCancellationRequested raises OperationCanceledException, never ObjectDisposedException — only CancellationToken.Register / WaitHandle can throw ODE post-dispose.

New regression tests (src/modules/launcher/Wox.Test/QuerySessionTest.cs, 9 tests, all passing)

Test	Asserts
CapturedToken_StaysBoundToOriginalSourceAcrossReplacement	Canonical #36041 regression. Creates session A, captures firstToken, creates session B, cancels A — asserts firstToken.IsCancellationRequested == true AND B.Token.IsCancellationRequested == false.
Cancel_SignalsCapturedTokenAndIsIdempotent	Cancel() is idempotent; captured-local token observes cancellation.
Start_PassesSessionTokenToPipelineFactory	The factory receives THIS session's token.
Start_ThrowsArgumentNullException_WhenFactoryIsNull	Defensive contract.
DisposeWhenComplete_WaitsForCompletionTaskBeforeDisposingCts	CTS is not disposed until the tracked completion task finishes.
CancelAndWait_ReturnsTrueWhenTaskCompletesWithinTimeout	Shutdown path success case.
CancelAndWait_ReturnsFalseWhenTaskExceedsTimeout	Shutdown path timeout case (buggy plugin doesn't yield).
Dispose_IsIdempotent_AndSafeAfterCancel	No double-dispose / no throw.
Token_ThrowIfCancellationRequested_NeverThrowsObjectDisposedException	Documents the property #7 above corrects.

Wox.Test: 139/139 passing.

Suggested manual smoke

1. Bug repro — hold a key in PT Run for 10–15s; watch PowerToys.PowerLauncher.exe thread count in Task Manager. Should stabilize, not climb monotonically.
2. Normal queries — Calculator (=2+2), file search, web search, indexer.
3. Final-sort path — Settings → PT Run → enable "Search query tuning" + "Wait for slow results", then query a slow plugin. Results should appear, then re-sort.
4. Race — type a slow query, then type more before it completes. Only the final query's results should remain.
5. Shutdown — Exit PowerToys with an in-flight query. Should exit cleanly in ≤2s, no orphaned processes.

Happy to back any of this out if you want a smaller diff — the SRP extraction is the bulk of it.