wallet2: remove refresh() from scan_tx #9389
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #9354
The problem
In #8566, I introduced a call to
refresh()
insidescan_tx
so that whenscan_tx
executes to completion, wallet data would reflect the latest chain state (e.g. the number of confirmations on the tx/tx's locked status would be up to date). I also introduced a new variablem_skip_to_height
to skip the wallet's refresh height to the tx's height if it hasn't synced to that height yet. The logic form_skip_to_height
mirrors the logic when a user includes a restore height when restoring the wallet.When refresh "skips" to
m_skip_to_height
(or a user restores a wallet at a provided restore height), the wallet downloads every block hash from the chain even from beforem_skip_to_height
(or provided restore height), which is (suspiciously) slow.Thus, when restoring a wallet and then calling
scan_tx
with a remote daemon,scan_tx
is slow to complete.The solution
This PR includes a simple fix to remove the call to
refresh()
insidescan_tx
.The other additional changes are there to ensure when
scan_tx
is called twice when the wallet is not yet synced to the height of txs scanned, those txs are reprocessed correctly (necessary change for this PR becausescan_tx
doesn't callrefresh()
anymore).Warning: when calling
scan_tx
when the wallet is not synced, the num confirmation data and locked status on scanned txs will not reflect the latest chain state with this change. A wallet must callrefresh
afterscan_tx
to get the latest state. Pinging @woodser on this since this reverts to behavior noted here.Misc. comment
@woodser suggested here to use the daemon's state to calculate things like num confirmations/locked status on a wallet's outputs, rather than use the wallet's latest sync state.
There are quite a few places where the wallet currently uses wallet state instead of daemon state. So it's a bit involved to decide exactly where daemon state should be used that won't break current wallet UX.
I'm proposing this PR as a simple fix for #9354 to improve current behavior.