test(content): give the loader concurrency tests real concurrency

Fixing the two failures that were stopping portable-headless earlier let
the job reach AcDream.Content.Tests for the first time on either
operating system - the test loop exits on the first failing project, so
the windows leg had never got past the apt step and the ubuntu leg had
never got past Core.Net. Two RetailDatLoaderTests cases were waiting
there, and they failed on both.

Both assert on RawDatabase.MaxConcurrentReads after issuing two Task.Run
reads that each block 40 ms in Thread.Sleep. A pair of pool work items is
not a guarantee of two workers in flight: on a low-core or saturated pool
the second queues behind the first, the reads run back to back,
MaxConcurrentReads stays 1, and the assertion fails for a reason that has
nothing to do with the loader. Pinning the suite to two CPUs on Ubuntu
reproduces it 5 times in 6; Windows is clean 6 of 6 at sixteen cores,
which is why nobody had seen it.

The pairs now start with TaskCreationOptions.LongRunning on the default
scheduler, which asks for a thread each. No assertion is changed - they
still fail if the loader serialises. The two coalescing cases moved onto
the same helper on purpose: two callers genuinely in flight is the
situation coalescing exists for, and a sequential pair was only ever
exercising a cache hit. Ten of ten clean under the same pin.

Release build green. App tests 4,152 / 3 skipped. Content 124 / 124.
Filed as #255.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-28 21:45:54 +02:00
parent 777f60708d
commit c7861020e1
3 changed files with 102 additions and 12 deletions

View file

@ -3320,6 +3320,22 @@ structural `spirv-dis` compare. The pinned NuGet native is already the pin.
the token, which still bounds the asynchronous wait. Ten of ten clean under
the same two-CPU pin afterwards. The test was not touched.
**And one the fixes uncovered.** With (3) and (4) gone, `portable-headless`
reached `AcDream.Content.Tests` for the first time on either operating system —
the workflow's test loop exits on the first failing project, so the windows leg
had never got past the apt step and the ubuntu leg had never got past Core.Net —
and two `RetailDatLoaderTests` cases failed on both. Same family again, and
again not the campaign's: they assert `MaxConcurrentReads` after issuing two
`Task.Run` reads that each block 40 ms, and a pair of pool work items is not two
workers in flight. Reproduced at 5 failures in 6 under the two-CPU pin, clean 6/6
on Windows. Both pairs now start with `TaskCreationOptions.LongRunning` so the
concurrency the assertions measure is actually offered; **no assertion changed**,
and the two coalescing cases get stronger for it, since a sequential pair only
ever exercised a cache hit. 10/10 clean under the pin. Filed as #255.
**Net effect on the V9 row:** the job is green, and so is the whole workflow —
its first fully green run is the evidence the row was waiting for.
### 5.4 The null-target `BeginPass` divergence (V4c) — ✅ DISCHARGED at V6k
> **Closed 2026-07-28 by V6k commit 2 (`eb7e6b4e`); see §5.5.16.** The answer is