Skip to content

Conversation

saikiran57
Copy link
Contributor

Fix related to issue: #31263

@DrahtBot
Copy link
Contributor

DrahtBot commented Jan 16, 2025

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31668.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

No conflicts as of last run.

@DrahtBot
Copy link
Contributor

🚧 At least one of the CI tasks failed.
Debug: https://github.com/bitcoin/bitcoin/runs/35699494417

Hints

Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:

  • Possibly due to a silent merge conflict (the changes in this pull request being
    incompatible with the current code in the target branch). If so, make sure to rebase on the latest
    commit of the target branch.

  • A sanitizer issue, which can only be found by compiling with the sanitizer and running the
    affected test.

  • An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

@maflcko
Copy link
Member

maflcko commented Jan 16, 2025

This needs a test and the tests fixed

@fanquake
Copy link
Member

Moved to draft for now. You'll need to squash your commits, and address the various review feedback.

@fanquake fanquake marked this pull request as draft February 20, 2025 20:47
@DrahtBot
Copy link
Contributor

DrahtBot commented Mar 3, 2025

🚧 At least one of the CI tasks failed.
Debug: https://github.com/bitcoin/bitcoin/runs/38094021491

Hints

Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:

  • Possibly due to a silent merge conflict (the changes in this pull request being
    incompatible with the current code in the target branch). If so, make sure to rebase on the latest
    commit of the target branch.

  • A sanitizer issue, which can only be found by compiling with the sanitizer and running the
    affected test.

  • An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

@DrahtBot DrahtBot removed the CI failed label Mar 3, 2025
@saikiran57 saikiran57 marked this pull request as ready for review March 3, 2025 12:13
@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch from 54a20e6 to c353883 Compare March 3, 2025 13:56
@mprenditore
Copy link

Moved to draft for now. You'll need to squash your commits, and address the various review feedback.

@fanquake code has been updated as per the discussions and all checks are now passing.
Hope now it's good to be merged.

@davidrobinsonau
Copy link

Cloned fresh bitcoin src, then "gh pr checkout 31668" and built on Ubuntu WSL2.
Confirmed importdescriptors with "timestamp":"now" causes "RescanFromTime: Rescanning last 16 blocks".
Confirmed importdescriptors with "timestamp":"never" returns in less then a second and no messages about rescanning blocks on bitcoind console.
Thank you!

@mprenditore
Copy link

Hello @maflcko @furszy @fanquake
Can this be merged now?

@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch 2 times, most recently from 630210e to 1ac3559 Compare March 19, 2025 15:56
Copy link
Contributor

@w0xlt w0xlt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to add test cases for the "never" option.

@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch from 1ac3559 to 8ebba0a Compare April 8, 2025 08:02
@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch from 8ebba0a to 7f3bb5c Compare April 8, 2025 11:02
@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch 2 times, most recently from ec8e5df to 5c21359 Compare June 3, 2025 06:32
@saikiran57
Copy link
Contributor Author

Hi @achow101 and @maflcko I've fixed your review comments.

Comment on lines 155 to 159
import_res = restorewo_wallet.importdescriptors(
[
{"desc": wo1_desc, "timestamp": "now"},
{"desc": wo2_desc, "timestamp": "now"},
{"desc": wo2_desc, "timestamp": "never"},
{"desc": wo3_desc, "timestamp": "now"},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test with now is basically the same as never. Since the distinction is that now does actually rescan a little bit, it would be good to add in the setup for these tests a transaction that would be scanned by now but not never.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @achow101 I've added more test cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @achow101 could you please share your thoughts with the latest changes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but your latest test changes do not really implement what I was suggesting.

My point was that you need to distinguish between now and never, and currently the tests do not do that. The outcome of rescanning due to "timestamp": "now" should be different from the outcome of not rescanning due to "timestamp": "never". As it is now, both tests have the same outcome due to the setup, so we don't know whether there is a bug in the handling of now or never.

My suggestion is not to make yet another copy of the same import and balance check as you have done. Rather, my suggestion is that you should change the setup such that rescanning with now produces a different result (i.e. balance) than with never.

One way you might do this is to change the above set_node_times so that the time used for now overlaps with some of the transactions that are made earlier in the test. An alternative could be to create a transaction after set_node_times but before any imports as such a transaction would definitely fall within the now rescan range. However, it may require other changes to the test as balances may change.

You may have a different idea on how to do that test, it's up to you to decide how to approach writing that. Either way, the difference in behavior between now and never should be tested here that demonstrates how now and never can have different outcomes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @achow101 Thanks for your suggestion, I hope i understand it correctly and I updated the test cases. Kindly review it again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @achow101 any update on the fix I provided.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @achow101 can you please review it again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @achow101 kindly give some update on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HI @achow101 can you please approve this PR

@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch from 5c21359 to 2fd0fd5 Compare June 4, 2025 08:43
@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch 2 times, most recently from e7ee990 to 8a67868 Compare June 12, 2025 14:43
@DrahtBot
Copy link
Contributor

🚧 At least one of the CI tasks failed.
Task lint: https://github.com/bitcoin/bitcoin/runs/43971724813
LLM reason (✨ experimental): The CI failure is caused by lint errors due to missing newline at the end of a Python test file.

Hints

Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:

  • Possibly due to a silent merge conflict (the changes in this pull request being
    incompatible with the current code in the target branch). If so, make sure to rebase on the latest
    commit of the target branch.

  • A sanitizer issue, which can only be found by compiling with the sanitizer and running the
    affected test.

  • An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

@saikiran57 saikiran57 requested a review from achow101 July 16, 2025 08:14
@mprenditore
Copy link

Hello, is possible to review it again? It should be all good now.
Thanks a lot for the support :)

@DrahtBot
Copy link
Contributor

Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

assert_equal(restorewo_wallet.getbalance(), 0)
assert_equal(len(restorewo_wallet.listtransactions()), 0)

# rescan will continue if any of the descriptors has now as timestamp
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“if any of the descriptors has now as timestamp” → “have” [plural agreement]
“if any of the descriptors has now or valid timestamp” → “have” [plural agreement]

@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch 2 times, most recently from 8a67868 to 8d625b8 Compare July 28, 2025 14:26
@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch from 8d625b8 to 43ec169 Compare July 30, 2025 11:53
@saikiran57 saikiran57 force-pushed the set_rescan_option_import_descriptors branch from 43ec169 to 6e523bd Compare July 30, 2025 11:56
@mprenditore
Copy link

Hello, anything still pending or can now be merged?

@achow101
Copy link
Member

achow101 commented Aug 8, 2025

Hello, anything still pending or can now be merged?

All PRs must be reviewed prior to being merged. This PR does not have sufficient review, so it cannot be merged.

@saikiran57
Copy link
Contributor Author

Hi all, could you please complete the review I've resolved all the comments of the previous review comments.

@saikiran57
Copy link
Contributor Author

Hi @furszy kindly acknowledge this review its been waiting for very long time.

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.

9 participants