-
Notifications
You must be signed in to change notification settings - Fork 667
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
Fix/2970 #3016
Conversation
…unconfirmed state, and in so doing, *never* leave the MARF trie open (#2970). Confirm this with a unit test.
…we can create invalid ones for testing)
Codecov Report
@@ Coverage Diff @@
## develop #3016 +/- ##
============================================
+ Coverage 28.15% 82.56% +54.40%
============================================
Files 242 242
Lines 195403 195667 +264
============================================
+ Hits 55025 161556 +106531
+ Misses 140378 34111 -106267
Continue to review full report at Codecov.
|
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.
lgtm
@pavitthrap can you sign the CLA? Thanks! |
@jcnelson could you add a note about this in |
This fixes #2970 by ensuring that the unconfirmed state MARF trie is always committed when processing unconfirmed microblocks, even if the microblocks are invalid.
Thanks to @wileyj, I was able to identify the root cause of #2970: the node was processing an invalid microblock and then leaving the MARF open, which would then cause the node to crash when it attempted to mine a microblock (via
InProgressError
). The solution is to unconditionally close the unconfirmed state MARF trie, even if the unconfirmed microblock stream is bad. I have added a unit test that fails indevelop
but succeeds in this PR to demonstrate this.Almost as concerning is how the invalid microblock came to be. The microblock in question was invalid because it contained a transaction with a bad nonce. Moreover, this node mined it -- it produced a microblock that was valid at the time it was created, but later became invalid through some unknown means. I need to figure out why this is, but for the time being, this PR addresses the crash.