Repository navigation
test(bake): wait for the held compile stamp, never sample HeldCount (red on #6132 shard 5) - #6169
Conversation
AGatedSweepHearsItsOwnCompileTest.AProvisionalSweep_ReportsCompiled_ThoughItsStampIsHeld read MeshPublicationGate.HeldCount once, right after the warm answered Compiled. By design the process-local witness (LocalNodeTypeBuilds) is published BEFORE the stamp, and the stamp is offered to the gate only after the release-create observation completes — so the read could land in between and see 0 (core #6132 shard 5, run 37338956752: 'Expected 0 to be greater than 0 because the compile stamp waits for the bake's verdict'; #6132 touches none of this). The test now waits for HeldCount > 0 within TestTimeouts.Convergence, then checks the record does not carry the build. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Test Results (shard 4)0 tests 0 ✅ 0s ⏱️ Results for commit 9f28073. |
Test Results (shard 5)0 tests 0 ✅ 0s ⏱️ Results for commit 9f28073. |
Test Results (shard 3)0 tests 0 ✅ 0s ⏱️ Results for commit 9f28073. |
Test Results (shard 0) 1 files - 2 1 suites - 2 2m 17s ⏱️ - 1m 7s Results for commit 9f28073. ± Comparison against base commit 64a828a. This pull request removes 566 and adds 598 tests. Note that renamed tests count towards both. |
Test Results (shard 1)510 tests - 1 243 510 ✅ - 1 241 6m 19s ⏱️ +37s Results for commit 9f28073. ± Comparison against base commit 64a828a. This pull request removes 1753 and adds 510 tests. Note that renamed tests count towards both. |
Test Results 2 files 2 suites 8m 36s ⏱️ Results for commit 9f28073. |
Red
Core #6132 shard 5 (run 37338956752) failed in
MeshWeaver.Hosting.Test.AGatedSweepHearsItsOwnCompileTest.AProvisionalSweep_ReportsCompiled_ThoughItsStampIsHeldwithExpected 0 to be greater than 0 because the compile stamp waits for the bake's verdict. #6132 (instance reboot) touches nothing on this path: not the publication gate, the pre-warmer or the compile pipeline. So this is a race in the test that can hit any PR.Root cause
The test reads
MeshPublicationGate.HeldCountonce, straight afterWarmOneanswersCompiled. The two events it compares are ordered the other way round on purpose:DynamicTypePreWarmer.WarmOneanswers from the process-local witness (LocalNodeTypeBuilds), which "is published BEFORE the (possibly held) stamp" (Broken NodeType BinaryClickerV2/BinaryToggle never bakes, failing nodetype_bake readiness and stalling portal rollouts #5544).admission.Publish("NodeType compile stamp for …")inNodeTypeCompilationHelpers) only inside the release-create observation's subscription, which comes later.So the single read can land between the two and see 0.
Fix (test only)
Wait for
HeldCount > 0withinTestTimeouts.Convergenceinstead of sampling it, using the sanctioned interval re-query. Then check that the shared record does not carry the build; that check is now made once the stamp is known to be held, which is what makes it meaningful. No bound is raised and production code is unchanged.Verification
MeshWeaver.Hosting.TestRelease-warnaserror: 0 warnings, 0 errors.--filter AGatedSweepHearsItsOwnCompileTest: 2/2 pass locally.Pairs-with: none — test-only change; no public surface touched.
🤖 Generated with Claude Code