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

docs: file #321 — a THIRD load-sensitive test failure, filed rather than absorbed

Browse source 
A DatSoundCacheTests concurrent-decode-dedup fact failed once under full-suite
load during C5a's commit-1 standalone verification and passed clean in
isolation.

Filed as its own issue deliberately. It is neither #302 (PortalProjectionTests
GC-allocation, App.Tests) nor #308 (NakEmissionTests wall-clock, Core.Net.Tests),
and the standing rule that those two must never be conflated exists precisely
because absorbing a new intermittent into an existing "flake class" is how a
real defect gets dismissed as noise.

What is genuinely unknown is whether this is a fixture race or a thread-safety
defect in the decode cache itself. That distinction is load-bearing:
DatCollection is already recorded in project memory as NOT thread-safe, so an
audio decode cache racing under load would be the same family rather than a
coincidence. The first step is a repeat/stress run of Core.Tests alone — load-
only means scheduling pressure, reproduction in isolation means a real race.

Explicitly no retry, Skip, or delay: a masked race is worse than a red test.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-05 14:12:29 +02:00
parent 6921a02744
commit 0257844106
1 changed files with 32 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

32
docs/ISSUES.md
View file

@ -13454,3 +13454,35 @@ lines.
Full analysis, with the headless test's structural immunity explained:
[`2026-08-05-local-player-child-propagation.md`](research/2026-08-05-local-player-child-propagation.md)
## #321 — `DatSoundCacheTests` concurrent-decode-dedup fails under full-suite load
**Status:** OPEN
**Severity:** LOW (test-only so far; no production symptom observed)
**Filed:** 2026-08-05
**Component:** content / audio cache
Surfaced during C5a's commit-1 standalone verification: a concurrent
decode-dedup fact in `DatSoundCacheTests` failed once under full-suite load in
`AcDream.Core.Tests` and passed cleanly when re-run standalone.
**Filed separately ON PURPOSE.** It is NOT #302 (`PortalProjectionTests`
GC-allocation assertion, App.Tests) and NOT #308 (`NakEmissionTests.LossSoak_…`
wall-clock deadline, Core.Net.Tests). The standing handoff rule is that those
two must never be conflated; a THIRD load-sensitive failure absorbed into "the
flake class" is exactly how a real intermittent defect gets dismissed as noise.
**What is actually unknown:** whether this is a test-harness race (two threads
racing the dedup latch in the fixture) or a genuine thread-safety defect in the
decode cache itself. The distinction matters — `DatCollection` is already
recorded in project memory as NOT thread-safe, and an audio decode cache racing
under load would be the same family rather than a coincidence.
**First step, before treating it as noise:** run `AcDream.Core.Tests` alone
under repeat/stress to see whether it reproduces without full-suite load. If it
only fails under load it is scheduling pressure; if it reproduces in isolation
under repetition, it is a real race and should be escalated out of LOW.
Do not add a retry, a `Skip`, or a delay to make it green — this campaign's
standing rule is no workarounds without explicit approval, and a masked race is
strictly worse than a red test.