Skip to content

Conversation

@Tomas-M
Copy link
Contributor

@Tomas-M Tomas-M commented Nov 16, 2025

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_scanned and percentage_total_outputs_scanned fields. Sync completion is determined reliably by numeric threshold.

@fluidvanadium
Copy link
Contributor

Read, tested, looks good. But needs one more pair of eyes on it.

Copy link
Member

@zancas zancas left a 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.

Ok(json_val) => {
// Extract both percentage fields as f64.
let blocks_pct_opt = json_val
.get("percentage_total_blocks_scanned")
Copy link
Member

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!

// Extract both percentage fields as f64.
let blocks_pct_opt = json_val
.get("percentage_total_blocks_scanned")
.and_then(|v| v.as_f64());
Copy link
Member

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.

@Tomas-M
Copy link
Contributor Author

Tomas-M commented Nov 21, 2025

I agree, thanks for feedback.
I will find a better way.

@Tomas-M Tomas-M requested a review from zancas November 21, 2025 22:32
@Tomas-M
Copy link
Contributor Author

Tomas-M commented Dec 1, 2025

any chance to review this again and possibly accept it? Thanks

@Tomas-M
Copy link
Contributor Author

Tomas-M commented Dec 5, 2025

@zancas @fluidvanadium
Is there any other change needed? I will happily do what it takes to have this accepted, since it improves my previous code regarding --waitsync which I feel responsible for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants