Retiring xunit — what the in-mesh migration removes, and what it does not

Measured 2026-09-18 on MeshWeaver.Plugins main (b0d32552d), read-only, with scripts/xunit1069-sites.py over the tree and scripts/generate-in-mesh-suites.py as the conversion ledger. Both are committed; re-run them rather than trusting this page's numbers.

The question this answers (maintainer, 2026-09-18): of the 2,308 xUnit1069 sites in #2031, how many live in suites the migration deletes or converts — N of 2,308 — and what is the residue?

The denominator, reproduced from source

xUnit1069 fires on a [Fact(Timeout = …)] / [Theory(Timeout = …)] method whose body does not reference TestContext.Current.CancellationToken. #2031 counted 2,308 sites from one CI run's log (35199866577). That log is partial by construction — it is attempt 2, and 12 of the 40 projects with sites (MeshWeaver.AI.Test among them, 270 sites) did not run in it — so the denominator has to come from the tree:

The rule is checked against the run: for the 28 projects the log does carry, source and log agree within the commits landed since (MeshWeaver.Security.Test 218 = 218; Hosting.Monolith.Test 387 = 387; the rest ±1…5). 2,317 today is #2031's 2,308 plus a day of merges.

N of 2,317: what the two migration PRs remove

Zero. Neither PR deletes an xunit test file:

Both lay Testing/<Suite>/Source/*.cs down BESIDE src/*.Test; the xunit project stays, is still built by Build + test the portal hosts, and still emits every warning. A site disappears only when its xunit PROJECT is deleted — a project, not a file, because CI builds and declares tests per project (.github/ci-tests.json, scripts/project-closure.py).

So the honest question is which projects could be deleted once their in-mesh suite is green, and the generator's own ledger answers it:

And the project view is stricter still. 18 of the 83 test projects that carry test files convert completely, and every one of them carries 0 sites. Every project that has a site has a refused remainder (Hosting.Monolith.Test 53 of 184 files, AI.Test 107 of 241, Security.Test 3 of 50, Hosting.PostgreSql.Test 0 of 145), so none can be deleted by this converter.

Deleting everything the converter can convert today removes 0 of 2,317 sites. The 370 "convertible" sites sit in projects that cannot go.

The residue is real — and converting does not fix it, it hides it

Two findings that change what "convert" means for this warning:

1. The in-mesh runner has the defect xUnit1069 names. MeshTestRunner.RunCase (core src/MeshWeaver.Testing.InMesh) runs a case as Observable.FromAsync(...).Timeout(bound). The timeout emits ❌ FAIL — no verdict within Ns and moves to the next case; the awaited work keeps running, inside the gate's one portal process, with no token to observe. MeshTestContext exposes a Deadline and no CancellationToken. That is "a timeout that fires while the work it started keeps running" — the shape #2031 calls the live correctness risk — with no analyzer left to say so.
2. The converter un-fixes the fixed ones. convert-xunit-to-inmesh.py rewrites TestContext.Current.CancellationToken → CancellationToken.None. The 419 timed tests in 145 files that already pass the token would lose it on conversion.

So the count would fall by analyzer absence, not by behaviour. That is the outcome the task rules out ("not because 2,308 tests were decorated" applies in both directions: not decorated, and not undecorated).

What follows — the slice plan

The two directives reconcile as: fix the sites in a way that SURVIVES conversion, and retire suites by deleting projects as the facility allows. Passing the token is not decoration when the in-mesh runner honours it — it is the one change that is correct on xunit today and correct in-mesh tomorrow.

Slice 3 is the large one and it is the one that cannot be skipped: 84% of the sites live in files no converter reaches until the facility exists, and the facility is a core design, not a Plugins PR. A site fixed in slice 3 stays fixed through slice 6 because slice 2 makes the converter carry the token instead of dropping it.

What the plan does NOT do: decorate a site with the token while its awaited work ignores it (that is the analyzer's approval without the behaviour — core measured "707 tests satisfy xUnit1069; 271 helper-level waits still outlive the verdict" after its own pass), add a NoWarn, or delete a project whose in-mesh suite has not rendered green.

Both PRs as they stand

• core #4185 — draft. Its written blocker ("Draft until #4184 is on main") is stale: #4184 merged 2026-09-13. Its real blockers: 77 unanswered Copilot findings (71 on generated samples/Graph/Data/Testing/**, 6 on the converter) and CI last taken 2026-09-13 at head cc336bd1 against a base of the same day. Automatic review answered is a required context, so each finding blocks the moment the PR is undrafted. The findings are the same classes #1792's 12 named: async/await carried byte-for-byte into NodeType source, hand-rolled task gates, classes still deriving from bases the conversion did not bring, and converter defects (sole ITestOutputHelper constructor only, base substitution before constructor rewrite).
• Plugins #1792 — draft, disarmed since 2026-09-14, all 12 findings answered and valid. Its own body proposes the split this page adopts: converter and refusal ledger first, the reference set as a core change, one package per PR thereafter. compile-check (Testing) on its head: 130 errors (CS0234 ×114, 52 of them MeshWeaver.Reactive.Assertions).

Neither is restarted here. Slice 2 lands the converter fix on top of #1792's tooling (on main since #1789); slice 6 draws suites from #1792's branch one package at a time.

Reproduce

python3 scripts/generate-in-mesh-suites.py 2> /tmp/refused.txt     # lays Testing/<Suite>/Source down (untracked)
python3 scripts/xunit1069-sites.py --refusals /tmp/refused.txt      # sites, converted/refused, per project, per reason
git clean -fdq Testing                                               # the generated tree is not committed here