6bbb21a2

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>

Total

9s

Timeline