repro: pool truncation deletes history before the frontier fetch can fail

[dorianvp]

Claim

truncate_to_pool_activation_height in pepper-sync/src/sync.rs (lines 1626 to 1717) rewinds the wallet stores before it fetches the frontiers it needs to rebuild the shard trees. The store truncation at pepper-sync/src/sync.rs:1658 (truncate_stores(wallet, rescan_from - 1, false)?) deletes blocks, transactions, nullifiers and outpoints at or above rescan_from. The frontier fetch at pepper-sync/src/sync.rs:1660 (client::get_frontiers(fetch_request_sender, birthday).await?) comes after it. When the fetch fails, the function returns Err before state::reopen_scan_ranges_from (line 1703), add_scan_targets (line 1704) and set_save_flag (line 1706) run. The wallet is left with history deleted at or above rescan_from while the scan ranges covering those heights still read Scanned, so the deleted history is not rescanned.

What the test does

sync::test::pool_truncation_atomicity::frontier_fetch_failure_leaves_stores_and_scan_ranges_consistent builds a MockWallet on a LocalNetwork with Nu5 at height 20, a birthday of 10, wallet blocks at 15 and 25 and a single Scanned range 10..31. It drops the fetch request receiver so client::get_frontiers fails with ServerError::FetcherDropped, calls truncate_to_pool_activation_height for ShieldedPool::Orchard, and asserts the intended invariant: the block at 25 is either still present or the range covering it is no longer marked Scanned.

Observed failing output

wallet block at 25 deleted (retained: false) while its scan range is still marked scanned (true); scan ranges: [ScanRange { block_range: BlockHeight(10)..BlockHeight(31), priority: Scanned }]
test result: FAILED. 0 passed; 1 failed

This PR is a reproduction and not a fix. The sync-bench A/B rule was not run because the commit adds a test only.

🤖 Generated with Claude Code