Note that we refresh UTXOs from the start height of the block range that was scanned. Given that we do non-linear scanning now, this means we're potentially fetching weird subsets of the UTXO set for the wallet.
When I added transparent UTXO fetching to zec-sqlite-cli in https://github.com/Electric-Coin-Company/zec-sqlite-cli/pull/23, I instead implemented it by, just after calling update_chain_tip and before any shielded scanning in a scan cycle, fetching all UTXOs starting at the block-fully-scanned height (which is always increasing, and means we fetch the full block range where we have not scanned all shielded information).
We should do something similar here, adjusted for appropriate re-fetch frequency depending on how the sync state machine is implemented here.
Currently
refreshUtxosis triggered every time we finish scanning an individual block range: https://github.com/Electric-Coin-Company/zcash-android-wallet-sdk/blob/90bff3199cf9f21b83d3215f8bbcb38c67045ae2/sdk-lib/src/main/java/cash/z/ecc/android/sdk/block/processor/CompactBlockProcessor.kt#L478-L489Note that we refresh UTXOs from the start height of the block range that was scanned. Given that we do non-linear scanning now, this means we're potentially fetching weird subsets of the UTXO set for the wallet.
When I added transparent UTXO fetching to
zec-sqlite-cliin https://github.com/Electric-Coin-Company/zec-sqlite-cli/pull/23, I instead implemented it by, just after callingupdate_chain_tipand before any shielded scanning in a scan cycle, fetching all UTXOs starting at the block-fully-scanned height (which is always increasing, and means we fetch the full block range where we have not scanned all shielded information).We should do something similar here, adjusted for appropriate re-fetch frequency depending on how the sync state machine is implemented here.