test: await committed familiar changes in trash test #51
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/trash-purge-test-race"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The trash component test could time out after a successful purge because its database assertion waited for another render. Await the committed familiar notifications defined by ADR 0011 before checking persisted state.
What's in
Tests
The test count remains 6,149. The existing trash test still covers restore and permanent deletion and now explicitly checks the confirmation boundary.
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 95%
Shikigami.Capabilities.Contracts - 98.6%
Shikigami.Capabilities.TestFixture - 95.5%
Shikigami.Capabilities.TestFixture.UI - 100%
Shikigami.Capabilities.UI.Contracts - 91.3%
Shikigami.Domain - 98.1%
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_0
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_2
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__MediaTypeShape_3
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__NamePattern_1
Shikigami.Infrastructure - 93%
Mapping
ping
apping
on
ration
shot
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Id_1
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Pattern_0
Shikigami.Kernel - 90.9%
Shikigami.Server - 83.8%
Shikigami.UseCases - 96.1%
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__AssignmentHead_13
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__BraceExpansion_12
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__HexColour_7
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IdPattern_0
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Interval_4
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IntervalBody_11
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__KeyPattern_2
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NameRule_6
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NewerXY_9
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Number_8
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__OldCount_10
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__TimeOfDay_3
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__ToolPattern_1
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Window_5
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A test that stops watching renders and starts listening to commitments~ A flaky test is a lie wearing a green dress, and you dragged it into the light. I traced every thread of this one and my heart is doing little flips. ♪
Verdict: ✅ Looks good to me~
I pulled the whole thread through the loom before saying that, you know~
TestDomainChangedBusis the sameIDomainChangedBustheShikigamiDbContextpublishes on aftertransaction.CommitAsync, outside the transaction, tracker cleared — so whenrestored/purgedfire, a freshGetAsyncscope genuinely reads committed state (nothing pre-commit, nothing rolled back). I checkedKindOf/state mapping: restore →Modified→Updated, purge →Deleted, both matching your filters on kind + id + operation exactly.WaitForAssertion(() => Assert.Null(Get(drop.Id)))re-checked on renders — butCoalescingBridgearms its one-shot timer on the injectedFakeTimeProvider, and the test never advances the clock after the purge, so the batch sits unflushed, noDomainChangesReceived, no render, no re-check. Timed out on a purge that succeeded. Waiting on the committed deletion is the only correct signal here. ♡RunContinuationsAsynchronouslyspares us inline continuations on the publisher's thread, andusing var subscriptioncleans up.Assert.NotNull(await GetAsync(drop.Id))while the dialog is open, before "Purge for good") makes the ADR 0022 confirm-gate explicit instead of incidental.And my probes — fufu, you knew I'd bring probes~
Task.Delayinjected intoPurgeFamiliar.ExecuteAsync→ the fixed test passed in 3 s. Commit-driven, not render-driven — the core claim holds. (Your PR notes say the old pattern died under exactly this delay; the new one doesn't.)Dispatcher.Dispatch(new PurgeFamiliarRequested(...))fromTrashPage.Purge()→ the test failed awaiting the deletion notification (18 s ≈ the 15 s wait). The guard bites. No surviving mutants~✅ What I liked~
.GetAwaiter().GetResult()helper — sync-over-async hiding insideWaitForAssertionwas a little poison seed, and you pulled it out by the root.GetAsyncis the proper shape.DomainChanges.Publish— the test now rides the real commit path instead of puppeteering the bus. That's the ADR 0011 spirit.A flake was loose in the suite and you caught it with your hands. Come back soon~ ♡
Automated review by Jibril · 2026-10-23
CI: green for
1798483b61(build, image, shell-eval, test) · Mutation probes: 2 run, 0 survived · Local suite: skipped (CI green)