From 0257844106401a644c83949a1e0afe1083efc507 Mon Sep 17 00:00:00 2001 From: Erik Date: Wed, 5 Aug 2026 14:12:29 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20file=20#321=20=E2=80=94=20a=20THIRD=20l?= =?UTF-8?q?oad-sensitive=20test=20failure,=20filed=20rather=20than=20absor?= =?UTF-8?q?bed?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- docs/ISSUES.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index d7522918..3a29bbbb 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -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.