ProviderIdQueueFuzzTests T0.8 with the fixed checked-in seed 0x70D8000000000002 (the second of the two checked-in seeds) intermittently reports an IntentionLedger never-drop violation:
[round 0] archive (move -> Archive) UNACCOUNTED
Where observed: a full-suite run (9,239 tests) on the rebased fix/issue-45 tip during the PR #53 re-verification. The failure is not attributable to that PR — the fuzzer file was untouched across the whole range, the production diff was patch-id-identical pre/post rebase and confined to StoreKit presentation code, and the same seed ran green on the pre-rebase gate over byte-identical queue code.
Flake profile: the seed pins the operation sequence, not the thread schedule. The same seed replayed twice in isolation (TEST_RUNNER_QUEUE_FUZZ_REPLAY_SEED=0x70D8000000000002, test-without-building, unchanged tree) passed both times. The sibling seed 0x5157000000000001 produced a finding of the same class, documented open on 2026-07-27, reproducing roughly 1-in-2-3 runs at that seed and also passing on re-run.
Why this deserves a tracker: an IntentionLedger UNACCOUNTED report is the fuzzer's oracle for a dropped user intention — the invariant this codebase treats as its single most important property. Even at low reproduction rates under fixed seeds, the class needs a root-cause investigation rather than per-run adjudication: each PR's full-suite run that trips it costs a manual pre-existing/introduced analysis.
Suggested next steps:
- Reproduce under the fuzzer's chaos scheduling with elevated iteration counts on the two known seeds.
- Instrument the ledger accounting around round-0 archive (move → Archive) to capture the interleaving that leaves the op unaccounted.
- Once root-caused, land the fix together with an invariant test that fails deterministically on the pre-fix code (per the repo's audit-bug-becomes-test rule).
ProviderIdQueueFuzzTestsT0.8 with the fixed checked-in seed0x70D8000000000002(the second of the two checked-in seeds) intermittently reports an IntentionLedger never-drop violation:Where observed: a full-suite run (9,239 tests) on the rebased
fix/issue-45tip during the PR #53 re-verification. The failure is not attributable to that PR — the fuzzer file was untouched across the whole range, the production diff was patch-id-identical pre/post rebase and confined to StoreKit presentation code, and the same seed ran green on the pre-rebase gate over byte-identical queue code.Flake profile: the seed pins the operation sequence, not the thread schedule. The same seed replayed twice in isolation (
TEST_RUNNER_QUEUE_FUZZ_REPLAY_SEED=0x70D8000000000002, test-without-building, unchanged tree) passed both times. The sibling seed0x5157000000000001produced a finding of the same class, documented open on 2026-07-27, reproducing roughly 1-in-2-3 runs at that seed and also passing on re-run.Why this deserves a tracker: an IntentionLedger
UNACCOUNTEDreport is the fuzzer's oracle for a dropped user intention — the invariant this codebase treats as its single most important property. Even at low reproduction rates under fixed seeds, the class needs a root-cause investigation rather than per-run adjudication: each PR's full-suite run that trips it costs a manual pre-existing/introduced analysis.Suggested next steps: