What
SearchLocalResultIdentityTests — the case named "NON-VACUITY: a mid-flight write that does NOT change the message's identity…" — failed once during a full-suite run, on the assertion that the post-write read reflects the write:
(after?.isRead → false) == true
Re-running that suite in isolation immediately afterwards: 7 tests, ** TEST SUCCEEDED **. A second full-suite run over the same bytes also passed it.
Why it is worth tracking rather than shrugging off
The failing assertion is the test's own non-vacuity guard — the part that proves the scenario actually happened before the real expectation is checked. When a non-vacuity guard fails intermittently, the useful reading is not "the feature broke"; it is that the setup did not take effect within the window the test allows. That makes every green run of this test slightly less trustworthy, because the same timing can plausibly leave the guard satisfied while the scenario under test is only partly staged.
It exercises the account write queue together with the search read path, so the likely shape is an ordering or visibility window between the write landing and the subsequent read, rather than a defect in identity handling itself.
Observed
Wanted
- Determine what the test relies on to make the mid-flight write observable to the subsequent read, and whether that is guaranteed or merely usually fast enough.
- If it is a timing assumption, replace it with a deterministic wait on the actual completion signal rather than widening a tolerance.
- If the window is real in production code and not just in the test harness, that is the more interesting outcome and should be filed separately.
Acceptance
What
SearchLocalResultIdentityTests— the case named "NON-VACUITY: a mid-flight write that does NOT change the message's identity…" — failed once during a full-suite run, on the assertion that the post-write read reflects the write:Re-running that suite in isolation immediately afterwards: 7 tests,
** TEST SUCCEEDED **. A second full-suite run over the same bytes also passed it.Why it is worth tracking rather than shrugging off
The failing assertion is the test's own non-vacuity guard — the part that proves the scenario actually happened before the real expectation is checked. When a non-vacuity guard fails intermittently, the useful reading is not "the feature broke"; it is that the setup did not take effect within the window the test allows. That makes every green run of this test slightly less trustworthy, because the same timing can plausibly leave the guard satisfied while the scenario under test is only partly staged.
It exercises the account write queue together with the search read path, so the likely shape is an ordering or visibility window between the write landing and the subsequent read, rather than a defect in identity handling itself.
Observed
Wanted
Acceptance