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: handle burn chain flapping #4563
Conversation
@jcnelson I couldn't come up with a good reason why we couldn't just ignore the duplicate entry. Let me know if you see any potential problems from this. |
d80684c
to
b0b0c7d
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #4563 +/- ##
===========================================
+ Coverage 82.20% 82.31% +0.11%
===========================================
Files 404 404
Lines 293057 293191 +134
===========================================
+ Hits 240909 241350 +441
+ Misses 52148 51841 -307 ☔ View full report in Codecov by Sentry. |
Can you actually base this on |
Heads up: I will reapply these changes on |
This test (from Jude) can reproduce the problematic behavior when the burnchain flaps between two branches. - We get blocks at height 211 - 213 - Then we get a fork, with different blocks at 211-213, as well as 214 and 215. - We then flap back to the original fork, so it goes back to the common ancestor, 210, and tries to download 211-215 - When it gets block 211, it is already in the database, so it fails, cancelling the download of the rest of the blocks, leaving 214 and 215 in this branch not stored - Then we try to store 216, but its parent 215 is not stored yet, so we cannot continue. The fix for this is to ignore attempts to store duplicate blocks.
b0b0c7d
to
6c9010c
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.
LGTM -- just a few comments
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. Just make sure CI passes 🙏
Hmm, the new tests failed with |
Not that I know of, but we might get a better error from CI with this map_err removed (since you added Debug to the error anyways): btcd_controller
.start_bitcoind()
.map_err(|_e| ()) |
This test passes locally but fails in CI. We cannot let it hold back this PR, so comment it out for now.
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.
Approving for now, but we need to get that CI test working
This test (from Jude) can reproduce the problematic behavior when the burnchain flaps between two branches.
The fix for this is to ignore attempts to store duplicate blocks.
Description
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/rpc/openapi.yaml
andrpc-endpoints.md
for v2 endpoints,event-dispatcher.md
for new events)clarity-benchmarking
repobitcoin-tests.yml