fix: preserve JUnit results after session cancellation

[Sing303]

Description

When a test session is cancelled, TUnit can finish without producing its JUnit report even though it has already received test results. MTP 2.4.1 passes the cancelled application token to AfterRunAsync; forwarding it to File.WriteAllTextAsync cancels report persistence too.

Persist the received results with CancellationToken.None. The existing retry and I/O error behavior stays intact. A cancelled run still exits unsuccessfully, and unfinished tests retain the writer's existing Test never finished error. This covers cooperative session cancellation, not forced process termination.

Related Issue

No existing issue found for this specific JUnit cancellation failure. The MTP call path is CommonTestHost.AfterRunAsync at the 2.4.1 source revision.

Type of Change

• Bug fix

Validation

• Reproduced with official TUnit 1.68.17 / MTP 2.4.1 on Windows and Linux: one completed test plus a cancellable infinite delay, with --timeout 5s, leaves the results directory empty.
• Added a reporter regression covering passed, failed and unfinished test results, with both active and already-cancelled tokens. Before the fix, the cancelled case fails with TaskCanceledException; after it, all 8 JUnitReporterTests cases pass.
• A separate process using the changed engine and reflection discovery writes both the completed and unfinished test cases after --timeout 5s; the run remains aborted with a nonzero exit code.

dotnet test --project tests/TUnit.Engine.Tests/TUnit.Engine.Tests.csproj -c Release -f net10.0 --no-restore --treenode-filter "/*/*/JUnitReporterTests/*" --minimum-expected-tests 8 --report-trx

Checklist

• Read the contributing guidelines.
• Added a regression test that fails before the fix.
• Ran the affected test class: 8 passed, 0 failed, 0 skipped.
• The reporter is shared by source-generated and reflection execution; no discovery, generated output or public API changed.
• Full repository test suite (not run; validation was scoped to this reporter).

Summary by CodeRabbit

• Bug Fixes
  • JUnit reports are now written even when run cancellation has been requested, preserving passed, failed, and unfinished test results.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: b9adfc93-691b-4c1f-a27d-ec8e5440d94f

📥 Commits

Reviewing files that changed from the base of the PR and between 6c034d0 and 39b54e2.

📒 Files selected for processing (2)

• src/TUnit.Engine/Reporters/JUnitReporter.cs
• tests/TUnit.Engine.Tests/JUnitReporterTests.cs

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

JUnitReporter.AfterRunAsync writes the XML report with CancellationToken.None. A parameterized test checks that passed, failed, and unfinished test cases appear in the report with and without run cancellation.

Changes

JUnit report writing

Layer / File(s)	Summary
Complete JUnit report writing src/TUnit.Engine/Reporters/JUnitReporter.cs, tests/TUnit.Engine.Tests/JUnitReporterTests.cs	AfterRunAsync writes the report without the run cancellation token. The test checks the XML output for passed, failed, and unfinished test cases when cancellation is requested and when it is not. It removes the temporary output directory in finally.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 39b54

No actionable issue remains in the supplied change; it is mergeable after normal checks.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 39b54

Cancelled runs can now leave a JUnit report containing results received before cancellation. The review found no changed report destination, access control, or result format. Report writing may continue to delay shutdown during file-lock retries.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed persistence window is limited to JUnit output from an enabled reporter after cooperative cancellation. The code does not show a new content source, destination, or privilege, though production consumers of the resulting file were not established.

Trust Boundaries and Controls

• observed — An environment-provided report path is normalized and validated, and an explicitly set path passes through the same validator. The token change occurs after path resolution and does not change those controls.

Resilience and Maintainability Implications

• inferred — Cancellation no longer bounds this writer's file operation or lock-retry delay. Whether a host shutdown deadline limits that continuation is unestablished, so no security failure-containment breach is asserted.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: preserving JUnit results after session cancellation.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit watched the test run end,
The report still reached its file.
Three cases waited in the XML,
Passed, failed, unfinished in a row.
The rabbit thumped and hopped away.}

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Changes how test results are written when execution is cancelled.

The PR appears safe to merge; no actionable regression was identified.

Summary

The PR keeps JUnit report persistence active after session cancellation and adds a regression test for completed, failed, and unfinished results.

• The reporter now writes with CancellationToken.None while leaving its retry and I/O handling unchanged.
• The test checks report contents with both active and already-cancelled tokens.

Diagram

sequenceDiagram
  participant Host
  participant Reporter
  participant File
  Host->>Reporter: Test-node updates
  Host->>Reporter: AfterRunAsync(cancelled token)
  Reporter->>Reporter: Generate XML from received updates
  Reporter->>File: Write XML without session cancellation

Loading

_{Reviews (1) · Last reviewed commit: "fix: preserve JUnit results after sessio..."}

[github-actions]

Review: fix: preserve JUnit results after session cancellation (#6882)

Summary: Small, well-scoped fix. JUnitReporter.AfterRunAsync now writes the XML report with CancellationToken.None instead of forwarding the caller-supplied token, so a session cancellation (Ctrl+C, --timeout) no longer discards already-collected results before they can be persisted.

What I checked:

• The change is consistent with existing precedent in the codebase: HtmlReporter.cs (src/TUnit.Engine/Reporters/Html/HtmlReporter.cs:307,400) already uses CancellationToken.None for its must-complete write/lock-acquire paths, so this is aligning JUnitReporter with an established pattern rather than introducing a new one.
• GitHubReporter equivalent write path never threaded a cancellation token through to its I/O in the first place, so there is no remaining sibling-file inconsistency to flag.
• The new test AfterRunAsync_Should_Preserve_Results_When_Run_Is_Cancelled is parameterized over cancelled and non-cancelled tokens, covers passed/failed/unfinished result states, uses env vars unique to this file (safe under [NotInParallel]), and cleans up via try/finally. It fails before the fix and passes after, matching the PR description.
• No prior automated reviews (CodeRabbit, Greptile) raised blocking issues; both concluded "no actionable comments" and flagged the same low-severity theoretical concern noted below, which was never called out as a required fix.

Minor note (non-blocking): With CancellationToken.None, the retry-with-backoff write loop (up to EngineDefaults.FileWriteMaxAttempts attempts) now always runs to completion during shutdown, even if the file is locked by another process, and File.WriteAllTextAsync is not atomic (no write-to-temp-then-rename). If the host process is force-killed mid-retry during a cancelled run, that could leave a truncated or corrupt XML file where previously no file would have been written at all. This tradeoff already exists in HtmlReporter, which uses the same pattern, so it is not a regression introduced by this PR, just worth keeping in mind if a fast-cancel scenario ever matters for this reporter.

Overall this change looks correct and is well tested. Good to merge from my perspective.

[thomhurst]

Thanks!