By: Greg Pfeil <greg@technomadic.org>
qa: wait for the wallet to scan the tip before asserting balances `wallet.py` waited for `wallet_tip` to reach the node tip and then read `z_gettotalbalance`, allowing a five-block tolerance for the balance to catch up. That tolerance was fitted to observation rather than derived, and the quantity it approximates is bounded by something much larger: zallet reports itself synced -- and `getwalletstatus` reports `locked: false` -- while `fully_synced_height` trails the tip by up to `sync.lock_threshold` blocks, 100 by default. `wallet_tip` is how much of the chain the wallet has seen; balances are computed from what it has scanned. The test therefore asserted against a partial balance whenever the scan happened to be more than five blocks behind, which is permitted anywhere in that 100-block window. One observed failure reported 43 coinbases at a tip of 101, which is 58 blocks of lag; 46 and 60 have also been seen. Add `wait_for_wallet_scan`, which waits on `fully_synced_height` reaching the node tip, and use it wherever an assertion depends on the wallet having seen every output up to the tip. Waiting on the right quantity makes the expected balance exact, so the assertions become equalities against the block subsidy rather than ranges, and neither the tolerance nor the `wait_for_total_balance` poll layered on top of it is needed. `wait_for_wallet_sync` is left alone. It has callers that wait on accounts whose `fully_synced_height` is legitimately absent -- a recovered account still scanning the tip region -- where the stricter wait could not succeed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>