-
Notifications
You must be signed in to change notification settings - Fork 38.8k
test: fix race condition in encrypted wallet rescan tests #27199
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
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
Is this a draft because you haven't tested under Valgrind yet? Could add to the PR description what needs doing. |
|
Worked for me under a recent Valgrind run. |
Yes, it was.
Great, I will mark it as ready for review. |
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.
Any reason to use the cli, when the normal rpc can be used directly?
Also, I wonder if this introduces another race where the actual rescan in t.start() is scheduled after this call. Avoiding this race might be ugly, but I think it could be possible by using assert_debug_log with a timeout value to sync on the rescan actually starting?
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.
Any reason to use the cli, when the normal rpc can be used directly?
When I use the normal RPC directly, I get a CannotSendRequest error.
Also, I wonder if this introduces another race where the actual rescan in t.start() is scheduled after this call.
Yes, it does. I have used assert_debug_log with a timeout of 5 to fix this.
a4278ad to
92777b3
Compare
92777b3 to
308ea03
Compare
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.
Calling the cli constructor does not dispatch the rpc.
Otherwise this looks really nice.
I've tested this with https://github.com/bitcoin/bitcoin/pull/26347/commits/6a5b348f2e526f048d0b448b01f6c4ab608569af#r1133856319
maflcko
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.
looks nice, but there is a bug ACK 308ea03d95786db674e8cce3e78a56b498cf119a 🤠
Show signature
Signature:
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: looks nice, but there is a bug ACK 308ea03d95786db674e8cce3e78a56b498cf119a 🤠
dsqqD3bytDg6ZUqhxFkcRuKux2dfw85m+3T2vlhaQUQ3b4l8EkXyTYeSWzPpfL9zx9/SGYpqZiYJTY2x8tWODA==
308ea03 to
78cd77e
Compare
|
Didn't re-test. Please advise maintainers if you want this merged or work on coverage for review ACK 78cd77e17719d56366c483d5508cad7b0c5f1b5c 🏟 Show signatureSignature: |
78cd77e to
dbeca79
Compare
|
nice re-ACK dbeca79 🚜 Show signatureSignature: |
|
Also, tested with my diff from #26347 (comment) |
|
ACK dbeca79 |
…can tests dbeca79 test: fix race condition in encrypted wallet rescan tests (ishaanam) Pull request description: This fixes bitcoin#26347 (comment) ACKs for top commit: MarcoFalke: nice re-ACK dbeca79 🚜 achow101: ACK dbeca79 Tree-SHA512: 7127254ac0274b5bc8ba0242736e77464acbf1f6e3f6af098b4e47742124c336cd67dffdb385e1e8dbd3a8ae74acd073c99e82fa35c44a615fd7d22b29a0daf7
…can tests dbeca79 test: fix race condition in encrypted wallet rescan tests (ishaanam) Pull request description: This fixes bitcoin#26347 (comment) ACKs for top commit: MarcoFalke: nice re-ACK dbeca79 🚜 achow101: ACK dbeca79 Tree-SHA512: 7127254ac0274b5bc8ba0242736e77464acbf1f6e3f6af098b4e47742124c336cd67dffdb385e1e8dbd3a8ae74acd073c99e82fa35c44a615fd7d22b29a0daf7
mzumsande
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.
saw two fails of wallet_transactiontime_rescan.py --legacy-wallet today, both on master:
https://cirrus-ci.com/task/6620294484328448
https://cirrus-ci.com/task/4914078427119616
|
@mzumsande see also #27282. |
| self.nodes[0].cli("-rpcwallet=encrypted_wallet").walletpassphrase("passphrase", 1) | ||
|
|
||
| try: | ||
| self.nodes[0].cli("-rpcwallet=encrypted_wallet").walletlock() |
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.
It seems (?) we want this test to fail if walletlock succeeds, but that's not currently the case - is that on purpose? Apologies if I'm misunderstanding, I didn't dive super deep yet so feel free to keep your answer brief.
Edit: I suppose the main difficulty here is that walletlock can succeed if the rescan has already finished by the time walletlock is called, but then I think maybe the test needs a different setup?
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.
I suppose the main difficulty here is that walletlock can succeed if the rescan has already finished by the time walletlock is called
Yes, this issue here is that the rescan could have finished. For more context see: #27199 (comment)
then I think maybe the test needs a different setup?
It would be great if there was a way that this test could behave the same regardless of speed. We haven't been able to find a way to make that happen yet.
This fixes #26347 (comment)