Summary
wallet.py reads wallet state (z_gettotalbalance / z_listtransactions)
immediately after mining, before the embedded wallet has scanned and committed
the newly mined blocks. The transparent-balance assertion then races the wallet
scan and intermittently fails with 0 vs the expected 6.25.
Where
qa/rpc-tests/wallet.py, in the live run_test body: coinbase is mined and the
test asserts on the wallet view in the next statements, with no barrier that
waits for the wallet to reflect those blocks.
Observed failure
The transparent balance reads 0 (wallet not yet scanned) instead of 6.25
(coinbase matured into the wallet's view). Timing-dependent, so it presents as
flaky rather than a hard failure.
Root cause
There is no synchronous "wallet has finished syncing to height N" RPC to await
( tracked upstream in zcash/zallet#316 ). The legacy test was written assuming
the wallet view is immediately consistent after mining, which is not true for
the zallet embedded-wallet model — the scan is asynchronous.
Note: this race was previously masked by an unrelated zallet sync crash
("Missing Orchard tree state") — see References. Once sync reaches the
wallet-scan stage, the race becomes observable.
Proposed fix
Until a synchronous wallet-sync RPC exists (zcash/zallet#316), poll for the
expected wallet view before the wallet-side assertions — i.e. wait for the
transparent balance / expected transaction count to appear, then assert. This
mirrors the sync-barrier idiom used in the migrated tests.
A fix is prepared on branch fix/wallet-py-sync-race
(https://github.com/zcash/integration-tests/tree/fix/wallet-py-sync-race):
adds poll-barriers (wait_for_wallet_transparent / wait_for_wallet_txcount)
before the wallet-side asserts. Validated locally: wallet.py passes 3/3
consecutive runs with the barriers in place.
References
Summary
wallet.pyreads wallet state (z_gettotalbalance/z_listtransactions)immediately after mining, before the embedded wallet has scanned and committed
the newly mined blocks. The transparent-balance assertion then races the wallet
scan and intermittently fails with
0vs the expected6.25.Where
qa/rpc-tests/wallet.py, in the liverun_testbody: coinbase is mined and thetest asserts on the wallet view in the next statements, with no barrier that
waits for the wallet to reflect those blocks.
Observed failure
The transparent balance reads
0(wallet not yet scanned) instead of6.25(coinbase matured into the wallet's view). Timing-dependent, so it presents as
flaky rather than a hard failure.
Root cause
There is no synchronous "wallet has finished syncing to height N" RPC to await
( tracked upstream in zcash/zallet#316 ). The legacy test was written assuming
the wallet view is immediately consistent after mining, which is not true for
the zallet embedded-wallet model — the scan is asynchronous.
Note: this race was previously masked by an unrelated zallet sync crash
("Missing Orchard tree state") — see References. Once sync reaches the
wallet-scan stage, the race becomes observable.
Proposed fix
Until a synchronous wallet-sync RPC exists (zcash/zallet#316), poll for the
expected wallet view before the wallet-side assertions — i.e. wait for the
transparent balance / expected transaction count to appear, then assert. This
mirrors the sync-barrier idiom used in the migrated tests.
A fix is prepared on branch
fix/wallet-py-sync-race(https://github.com/zcash/integration-tests/tree/fix/wallet-py-sync-race):
adds poll-barriers (
wait_for_wallet_transparent/wait_for_wallet_txcount)before the wallet-side asserts. Validated locally:
wallet.pypasses 3/3consecutive runs with the barriers in place.
References
getwalletstatusRPC method zallet#316(fix proposed: sync: Treat an absent shielded tree state as an empty note commitment tree zallet#455, "Treat an absent shielded tree state as an
empty note commitment tree", open + mergeable)