test: Added test to ensure log and failure happen when work is less than active chainstate #30105
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. 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. |
kevkevinpal
force-pushed
the
assumeutxoExceedActiveChainstatelog
branch
4 times, most recently
from
641c0fa
to
de7ac86
Compare
|
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
| @@ -237,6 +237,9 @@ def run_test(self): | |||
| # will allow us to test n1's sync-to-tip on top of a snapshot. | |||
| self.generate(n0, nblocks=100, sync_fun=self.no_op) | |||
|
|
|||
| with n0.assert_debug_log(expected_msgs=["[snapshot] activation failed - work does not exceed active chainstate","[snapshot] activation failed - population failed"]): | |||
There was a problem hiding this comment.
Made a temporary modification of a word in the expected message (of feature_assumeutxo.py to test that a mismatch would be caught (it was, as expected). Restored to original expected message then modified the message in validation.cpp. This mismatch was also detected (as expected)l.
Line 5659 in 695d801
The default timeout for assert_debug_log() is 2 seconds. I haven't had a chance to dig deeper yet, but are we confident there isn't a potential timing issue with the message arriving into the debug log later than 2 seconds? (e.g. a late arrival potentially causing an intermittent test failure). I haven't encountered this, but only ran the tests a few times.
There was a problem hiding this comment.
Thanks for the review!
I think the timeout should be fine there is even a comment pointing out that we check the work twice because we want to fail fast
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L5655-L5657
There was a problem hiding this comment.
Make successful, all functional tests also. Asked a question and provided a suggestion.
@kevkevinpal Should we get rid of this TODO on line 26 now?
https://github.com/bitcoin/bitcoin/blob/master/test/functional/feature_assumeutxo.py#L26
| @@ -237,6 +237,9 @@ def run_test(self): | |||
| # will allow us to test n1's sync-to-tip on top of a snapshot. | |||
| self.generate(n0, nblocks=100, sync_fun=self.no_op) | |||
|
|
|||
| with n0.assert_debug_log(expected_msgs=["[snapshot] activation failed - work does not exceed active chainstate","[snapshot] activation failed - population failed"]): | |||
| assert_raises_rpc_error(-32603, "Unable to load UTXO snapshot", n0.loadtxoutset, dump_output['path']) | |||
There was a problem hiding this comment.
@kevkevinpal We are loading the snapshot of n0 in n0 itslelf? Should it not be loaded into n1?
There was a problem hiding this comment.
Thank you for the review!
yes, we should be able to remove that TODO: (removed in ac1b0e3)
I used n0 instead of n1 because if we use n1 it will properly work because n1 is not synced up yet. So I used n0 to loadtxoutset of a chainstate which is certain to be older than its current chainstate
There was a problem hiding this comment.
I see, though it seemed unusual initially that we are loading a snapshot in the same node. But now that I think more about it - this can happen in a real world scenario as well, right? Eg: When the node is re-started after a long time and needs to catch up to the latest blocks.
…han active chainstate Signed-off-by: kevkevinpal <oapallikunnel@gmail.com>
kevkevinpal
force-pushed
the
assumeutxoExceedActiveChainstatelog
branch
from
de7ac86
to
ac1b0e3
Compare
|
Just realised this is similar to this PR: #29428 |
|
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
Oh nice I didnt see this, closing this now |
This adds coverage to the
ActivateSnapshotfunction asserting that when we try to use a snapshot with too little work done on it, usingloadtxoutset. That this log and rpc error are thrownlog
[snapshot] activation failed - work does not exceed active chainstate[snapshot] activation failed - population failedrpc error
Unable to load UTXO snapshotAdds coverage to this code https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L5659