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
test: Bump walletpassphrase timeout to avoid intermittent issue #28089
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. |
self.nodes[1].walletpassphrase("test", 999999) | ||
signedTx = self.nodes[1].signrawtransactionwithwallet(fundedTx['hex']) | ||
self.nodes[1].sendrawtransaction(signedTx['hex']) | ||
self.generate(self.nodes[1], 1) |
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.
This looks fishy. It seems that we unlock the wallet inside a specific test case, and use the unlocked period for other test cases.
A better approach would be to relock the wallet at the end of this test case ( self.nodes[1].walletlock()
). And unlock-lock the wallet in the other cases when it is needed.
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.
Sounds good. An alternative might be to not use a passphrase after this test. Do you want to submit either as a pull request? Happy to close mine then. Otherwise, I'll leave the feedback for a follow-up, as the goal here is to not change any logic, only the constant.
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.
An alternative might be to not use a passphrase after this test
Yeah. Would be even better to create a wallet specific to this test and unload it at the end of it.
Do you want to submit either as a pull request? Happy to close mine then. Otherwise, I'll leave the feedback for a follow-up, as the goal here is to not change any logic, only the constant.
Will try to do it later today. Shouldn't take me much.
Still, all good if this one gets merged before it.
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.
ACK fa257a7
I would also ACK a PR that creates a wallet specific to this test as discussed above.
I think this PR can now be closed given #28139? |
Thanks, yes. |
…cked_wallet case c648bdb test: create wallet specific for test_locked_wallet case (furszy) Pull request description: Coming from bitcoin/bitcoin#28089 (comment). Several test cases are relying on the node1 default wallet, which thanks to 'test_locked_wallet' is encrypted. And can be only accessed within a specific timeframe (100ms), a duration internally set by the same test. This situation introduces a potential race condition, where other tests must complete their operations within the specified 100ms window to pass (otherwise the wallet gets re-locked and they fail). This can be seen running the test in valgrind (bitcoin/bitcoin#28089), where other test cases fail due the wallet re-locking itself after the 100ms. ACKs for top commit: MarcoFalke: lgtm ACK c648bdb ishaanam: utACK c648bdb Tree-SHA512: 01cde5a4a0cb3405adb9ea3c1f73841f3fa237d1162268ed06f0d49ca38541006b423a029e0b5e5955e1aa7e018c4600d894e555a68cf17ff60a4b8be58f4aa9
…let case c648bdb test: create wallet specific for test_locked_wallet case (furszy) Pull request description: Coming from bitcoin#28089 (comment). Several test cases are relying on the node1 default wallet, which thanks to 'test_locked_wallet' is encrypted. And can be only accessed within a specific timeframe (100ms), a duration internally set by the same test. This situation introduces a potential race condition, where other tests must complete their operations within the specified 100ms window to pass (otherwise the wallet gets re-locked and they fail). This can be seen running the test in valgrind (bitcoin#28089), where other test cases fail due the wallet re-locking itself after the 100ms. ACKs for top commit: MarcoFalke: lgtm ACK c648bdb ishaanam: utACK c648bdb Tree-SHA512: 01cde5a4a0cb3405adb9ea3c1f73841f3fa237d1162268ed06f0d49ca38541006b423a029e0b5e5955e1aa7e018c4600d894e555a68cf17ff60a4b8be58f4aa9
There is no risk increasing the timeout, but it avoids intermittent issues (when running in valgrind) of the form: