The Polecat incident-service sample's tests have not compiled since April, and nothing notices

[jeremydmiller]

src/Persistence/Polecat/PolecatIncidentService.Tests does not compile, and nothing notices, because the project is marked <Build Project="false" /> in wolverine.slnx. No CI target references it either — grep -rn PolecatIncidentService build/ .github/ returns nothing. It is invisible to every gate we have.

Found while verifying the JasperFx 2.39.5 upgrade (#3837): I built the solution-excluded projects directly to make sure the bump was clean across them, and this one failed. To be clear about attribution — the bump did not cause it. I re-ran the same build against JasperFx 2.37.0 and got the identical 13 errors, so this is pre-existing rot.

The failure

13 analyzer errors, all in test files, and TreatWarningsAsErrors=true makes them hard errors:

when_categorising_an_incident.cs(28,34):  VSTHRD103  ReadAsJson<CreationResponse<Guid>> synchronously blocks. Await ReadAsJsonAsync instead.
when_categorising_an_incident.cs(41,30):  xUnit1051  Calls to methods which accept CancellationToken should use TestContext.Current.CancellationToken
when_categorising_an_incident.cs(59,34):  VSTHRD103
when_categorising_via_asparameters.cs(30,34): VSTHRD103
when_categorising_via_asparameters.cs(40,31): VSTHRD103
when_categorising_via_asparameters.cs(45,30): xUnit1051
when_closing_an_incident.cs(27,34):       VSTHRD103
when_closing_an_incident.cs(36,31):       VSTHRD103
when_closing_an_incident.cs(57,34):       VSTHRD103
when_getting_an_incident.cs(26,34):       VSTHRD103
when_getting_an_incident.cs(34,31):       VSTHRD103
when_logging_an_incident.cs(45,32):       VSTHRD103
when_logging_an_incident.cs(49,30):       xUnit1051

Two rules, both mechanical:

• VSTHRD103 (10) — ReadAsJson<T> synchronously blocks; should await ReadAsJsonAsync. These are almost certainly leftovers from the xUnit v3 migration, where the analyzer set got stricter.
• xUnit1051 (3) — pass TestContext.Current.CancellationToken to methods that accept one.

The application project next to it, PolecatIncidentService, builds clean. Only the test project is broken.

Why it matters

This is the Polecat incident-service sample — the worked example a reader follows for Wolverine + Polecat. A sample whose tests do not compile is worse than no sample, because it is presented as known-good.

There is also a process question worth answering here rather than in isolation: Build Project="false" currently hides a project from every signal we have, and there is no inventory of what is hidden or why. This project has apparently not compiled since the slnx migration (1fb8e865b, 2026-04-08) — roughly four months — and nothing reported it once.

Suggested fix

1. Fix the 13 errors (ReadAsJsonAsync + TestContext.Current.CancellationToken).
2. Re-enable the project in wolverine.slnx so the solution build covers it, and confirm the tests actually pass rather than merely compile.
3. If it cannot be re-enabled for a real reason, put that reason in a comment next to the flag — an unexplained Build=false is indistinguishable from an accident.

Related: #3816 (a CI-target coverage guard, which would want to know about Build=false projects too).