TrxReport 2.4.0 force-kills host on cancellation

[thomhurst]

Describe the bug

Microsoft.Testing.Extensions.TrxReport 2.4.0 makes controller-backed TRX generation active on supported desktop operating systems even when --crashdump is not used. On the first graceful external cancellation, the controller terminates the child test host before its in-process cancellation path and cleanup hooks can complete.

This regresses working behavior with TrxReport 2.3.3.

Version used

• Microsoft.Testing.Extensions.TrxReport 2.4.0
• Microsoft.Testing.Platform 2.4.0
• .NET 10
• Reproduced on GitHub-hosted Ubuntu x64 and macOS arm64 runners

Steps To Reproduce

TUnit has four existing integration tests covering test-, class-, assembly-, and session-level cleanup after graceful external cancellation:

https://github.com/thomhurst/TUnit/blob/c50a120a73546c4ca50a519f94193998bec35e28/tests/TUnit.Engine.Tests/ExternalCancellationTests.cs#L22

1. Run a test application with --report-trx and a long-running test.
2. Send graceful cancellation/SIGINT to the test application.
3. Let the test framework handle cancellation and run its cleanup hooks.
4. Observe that all four marker files written by TUnit cleanup hooks are missing.

Failing CI evidence:

• Ubuntu: https://github.com/thomhurst/TUnit/actions/runs/33857415486/job/100973814966
• macOS: https://github.com/thomhurst/TUnit/actions/runs/33857415486/job/100973814973
• Triggering dependency update: thomhurst/TUnit@c50a120

Each test reports successful process cancellation, then fails because its expected cleanup marker does not exist. Reverting only TrxReport from 2.4.0 to 2.3.3 restores previous behavior.

Expected behavior

First/graceful cancellation should allow the child test host and test framework to process cancellation and finish registered cleanup/lifetime hooks. Forceful cancellation may terminate it.

Actual behavior

The controller kills the test host immediately when applicationCancellationToken is canceled, so in-process cleanup cannot complete.

The relevant behavior changed between these versions:

• In v4.3.3 / MTP 2.3.3, out-of-process TRX is selected only when --crashdump is set:
  https://github.com/microsoft/testfx/blob/v4.3.3/src/Platform/Microsoft.Testing.Extensions.TrxReport/TrxModeHelpers.cs#L15-L17
• In v4.4.0 / MTP 2.4.0, TRX uses controller mode whenever the OS supports it:
  https://github.com/microsoft/testfx/blob/v4.4.0/src/Platform/Microsoft.Testing.Extensions.TrxReport/TrxModeHelpers.cs#L33-L50
• Cancellation interrupts WaitForExitAsync, then the controller calls testHostProcess.Kill():
  https://github.com/microsoft/testfx/blob/v4.4.0/src/Platform/Microsoft.Testing.Platform/Hosts/TestHostControllersTestHost.ProcessLifecycle.cs#L127-L137

Controller-side lifetime handlers run after process exit, but they cannot recover in-process test-framework cleanup hooks after the child has been killed.

Additional context

TUnit temporarily excludes TrxReport 2.4.0 while retaining the other MTP 2.4.0 packages:

thomhurst/TUnit#6717

[Evangelink]

I confirmed this is a valid regression caused by two changes interacting. It is not the TRX writer itself killing the test process.

In MTP 2.3.3, plain --report-trx generated TRX in the application process. TUnit's graceful cancellation sends SIGINT to that process, so the first cancellation reaches TUnit and its test/class/assembly/session cleanup hooks can finish.

Two relevant changes altered that path:

1. Add generic ITestHostLauncher extension point + PackagedApp reference extension #9454 added generic controller-host launch support. When the controller's application token is canceled, WaitForExitAsync is interrupted and the controller immediately calls Kill() on its child. This was intended to ensure packaged, remote, or custom-launched hosts terminate and to let the controller reconcile their exit. This behavior already existed in 2.3.3, but plain TRX did not normally activate it.
2. Default TRX to controller-backed recovery #10808, released in MTP 2.4.0, made plain --report-trx controller-backed on supported desktop systems. Previously that mode was selected only with --crashdump. The change was intentional: a surviving controller can recover completed results from the TRX sidecar after crashes, hangs, and --timeout, instead of losing the whole report.

TUnit's CliWrap reproducer sends SIGINT to the PID it launched, which is now the controller. The controller treats that first cooperative cancellation as a reason to kill the child immediately. Consequently, the child never gets time to finish TUnit's in-process cleanup hooks. Controller-side finalization can still recover a TRX, but it cannot restore cleanup code that never ran.

The coverage gap in #10808 is that it tested normal completion and forced crash/hang/timeout recovery, but not graceful external cancellation plus child framework cleanup. The PR also deliberately provided no in-process opt-out.

The fix should preserve phased cancellation across the controller boundary: first request cooperative child cancellation and allow bounded cleanup; terminate only on forced cancellation or after a grace period. This needs to account for generic ITestHostHandle implementations, which currently expose Terminate() but no cooperative interrupt operation. I will also audit the other controller-backed extensions and reports so the change does not weaken crash, hang, timeout, retry, or custom-launcher behavior.