-
Notifications
You must be signed in to change notification settings - Fork 37
Fix waitsync operation and performance #2008
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
base: dev
Are you sure you want to change the base?
Conversation
…ng on fragile substring checks
|
Read, tested, looks good. But needs one more pair of eyes on it. |
zancas
left a comment
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.
Please don't use unnecessarily derived representations when the source quantity is directly observable.
zingo-cli/src/lib.rs
Outdated
| Ok(json_val) => { | ||
| // Extract both percentage fields as f64. | ||
| let blocks_pct_opt = json_val | ||
| .get("percentage_total_blocks_scanned") |
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.
Why use a percentage?
That's just a lossee re-representation of an underyling state, is it not?
Doesn't the percentage shift as a function of the denominator?
If it does not then isn't it just some fixed value... if it DOES... then isn't it reporting the same percentage for multiple different degrees of completion?!
Please don't use derived statistics when the actual observable underlying quantity is available.
If what we mean is 10 blocks from the tip, or 100 blocks unfinalized.. or whatever then lets use that!
zingo-cli/src/lib.rs
Outdated
| // Extract both percentage fields as f64. | ||
| let blocks_pct_opt = json_val | ||
| .get("percentage_total_blocks_scanned") | ||
| .and_then(|v| v.as_f64()); |
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.
Using the directly countable observables.. whatever they are will permit us to track values as e.g. u32.
The complexity introduced by floating point operations doesn't seem to paid for anywhere in this design.
|
I agree, thanks for feedback. |
|
any chance to review this again and possibly accept it? Thanks |
|
@zancas @fluidvanadium |
The waitsync loop relied on brittle string matching against the human-readable poll output. When the wallet was already synced, poll did not necessarily return the exact expected strings, causing the loop to wait indefinitely. This patch replaces this with a check that queries sync status in JSON form and reads the numeric
percentage_total_blocks_scannedandpercentage_total_outputs_scannedfields. Sync completion is determined reliably by numeric threshold.