-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add bulletproof rewind profiling #3618
feat: add bulletproof rewind profiling #3618
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most these changes look fine, a couple comments though.
@@ -105,7 +105,8 @@ pub async fn wallet_recovery(wallet: &WalletSqlite, base_node_config: &PeerConfi | |||
|
|||
let mut recovery_task = UtxoScannerService::<WalletSqliteDatabase>::builder() | |||
.with_peers(peer_public_keys) | |||
.with_retry_limit(3) | |||
// Do not make this a small number as wallet recovery needs to be resilient | |||
.with_retry_limit(100) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We made this smaller on purpose, if you have gone through your whole peer list 3 times something larger is wrong that trying 97 more times is not going to solve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to connect to a single peer in the list when the base node connection was not responsive posed to be a problem. I think it is much better for the user to stop the recovery process eventually than to restart it every time and hope for a quick connection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it's a small enough issue that I don't mind it going in but I still think that trying a 100 times when you have tried 3 times across all your peers and that many failed attempts tells you there is something wrong with the peers or your setup and you need to take action.
So I don't mind this going in BUT we use this in the Daily tests for that exact purpose, to tell us there is a problem with recovery. So if you want this to be 100 you need to cater for it in the way the Daily recovery test is launched so that it only has 3 retries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added configurable retry limit with default value 3.
- Added bulletproof rewind profiling measurements. - Improved wallet recovery resiliency with improved connection logic to the selected base node(s). - Improved recovering of seed words useability. - Inmproved some struct member names to be less confusing. - Improved revovery UTXO streaming performance by tuning the chunking parameter.
64b7bf1
to
754f1e7
Compare
* development: (29 commits) fix(pruned mode)!: prune inputs, allow horizon sync resume and other fixes (tari-project#3521) feat!: sending one-sided transactions in wallet_ffi (tari-project#3634) fix: use json 5 for tor identity (regression) (tari-project#3624) test: add operation_id to log messages (tari-project#3633) fix!: multiple monerod addresses in tari merge mining proxy (tari-project#3628) fix: get-peer command works with public key again (tari-project#3636) fix!: separate peer seeds to common.network (tari-project#3635) test: removed stress test log target (tari-project#3631) feat: removed transaction validation redundant events (tari-project#3630) feat: improve wallet responsiveness (tari-project#3625) feat: add bulletproof rewind profiling (tari-project#3618) fix!: console wallet grpc_console_wallet_addresss config (tari-project#3619) test: increase timeout in cucumber (tari-project#3621) chore: change status line (tari-project#3610) feat!: add tcp bypass settings for tor in wallet_ffi (tari-project#3615) feat: only trigger UTXO scanning when a new block event is received (tari-project#3620) feat: implement dht pooled db connection (tari-project#3596) feat: add page for detailed mempool in explorer (tari-project#3613) chore: add pub key in the dailes notify (tari-project#3612) feat: display network for console wallet (tari-project#3611) ...
Description
The following changes were made:
Results
The following tests were run using standard Tor connectivity on a laptop with an Intel(R) Core(TM) i7-7820HQ CPU and basic Samsung NVMe storage device.
Discussion
Motivation and Context
How Has This Been Tested?