erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: reopen #255, LongRunning is a hint and the test still flakes

Browse source 
The wire-stack audit's final full-suite gate turned up
AnimationCache_CoalescesSameDidAndAllowsUnrelatedReadsInParallel failing twice
in four runs on Windows, on a tree that already carries #255's LongRunning fix.
Run alone the project passes 124 of 124 every time. Both failures were
--no-build runs, which start faster and so crowd the machine harder, which is
the original diagnosis rather than a new one.

TaskCreationOptions.LongRunning asks for a dedicated thread. It does not
promise one, and it does nothing about the other eight test projects saturating
the box while these two forty-millisecond sleeps are supposed to overlap. The
assertion on MaxConcurrentReads is therefore still measuring the host.

The note suggests the shape that would actually close it: gate both threads on
a barrier so each is provably inside the read before either is released. Then
the count is a property of the loader instead of the scheduler and no amount of
load can move it. Filed rather than fixed because this session's diff is
confined to Core.Net, its tests, and docs, and the audit had no business
editing content loaders on its way past.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-29 02:07:19 +02:00
parent 081c2009d1
commit 41f74fcd2b
1 changed files with 29 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

30
docs/ISSUES.md
View file

@ -99,7 +99,9 @@ Copy this block when adding a new issue:
## #255 — Two RetailDatLoader concurrency tests measured the thread pool, not the loader
**Status:** DONE — 2026-07-28; the pair now runs on dedicated threads
**Status:** REOPENED — 2026-07-29; `AnimationCache_Coalesces…` still fails under
full-suite load on Windows despite the `LongRunning` fix (see the reopening note
at the end of this issue)
**Severity:** LOW (test infrastructure only; no production defect)
**Filed:** 2026-07-28
**Component:** tests / xUnit parallelism, content loaders
@ -134,6 +136,32 @@ afterwards.
**Files:** `tests/AcDream.Content.Tests/Vfx/RetailDatLoaderTests.cs`.
**Reopening note — 2026-07-29 (wire-stack audit session).**
`AnimationCache_CoalescesSameDidAndAllowsUnrelatedReadsInParallel` still fails
intermittently on Windows under full-solution load, on a tree that already
contains the `LongRunning` fix (`c7861020`, in the base lineage of this
session's `b70b9832`). Observed **2 failures in 4 full-suite runs**; the
project passes **124/124 every time it is run alone**. The two failures were
both `--no-build` runs, which start the projects faster and so apply more
parallel pressure — consistent with the original diagnosis rather than a new
cause.
`TaskCreationOptions.LongRunning` is a *hint*. It asks for a dedicated thread;
it does not guarantee one, and it does not stop the rest of the solution's test
host from saturating the machine while these two 40 ms sleeps overlap. So the
assertion on `RawDatabase.MaxConcurrentReads` is still measuring the host.
`PhysicsScriptLoader_AllowsConcurrentFirstReads` was not observed failing in
this session, but it shares the helper and should be treated as the same risk.
Suggested next step: stop asserting on observed parallelism. Gate the two
threads on a `Barrier`/`CountdownEvent` so both are provably inside the read
before either is released — then `MaxConcurrentReads == 2` is a property of the
loader, not of the scheduler, and the test cannot flake no matter how loaded
the box is.
This session changed nothing under `AcDream.Content`; its diff is confined to
`src/AcDream.Core.Net`, that project's tests, and `docs/`.
---
## #254 — Logout confirmation wait overran its timeout on a starved thread pool