-
Notifications
You must be signed in to change notification settings - Fork 123
fix: re-org bug introduced in microblock implementation #686
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
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/blockstack/stacks-blockchain-api/DUGTGH9qEBQCSAB7uH3NFLvtJCMd |
Codecov Report
@@ Coverage Diff @@
## develop #686 +/- ##
===========================================
+ Coverage 62.10% 64.15% +2.05%
===========================================
Files 78 78
Lines 7763 7767 +4
Branches 1205 1203 -2
===========================================
+ Hits 4821 4983 +162
+ Misses 2938 2780 -158
Partials 4 4
Continue to review full report at Codecov.
|
dcdcf14
to
10cc023
Compare
38da23c
to
1cc90ac
Compare
…o-orphaning" This reverts commit ed5b0c0.
a48dc24
to
4948f0a
Compare
4948f0a
to
4b81bad
Compare
🎉 This PR is included in version 0.63.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Closes #670
The gist of the problem is that immediately non-canonical anchor blocks were indiscriminately marking their associated microblock confirmations and txs as also non-canonical.
"Immediately non-canonical anchor blocks" referring to
/new_block
payloads received by the API for blocks that already have a canonical block at the same height.The fix was to add another condition to all sql queries that select or update from the
microblocks
table so that these anchor blocks have no effect on microblocks (and their associated transactions) that have already been confirmed by a previous, canonical anchor block.EDIT: the above fix caused a second re-org related bug that caused transactions to be incorrectly marked as anchor-block re-orged when a different order of event streams involving micro-orphans and anchor-orphans were ingested. This required microblock re-org detection and restoration being performed on all the same code paths as anchor block re-org restoration.
I've manually confirmed the fix works by reproducing the bug using the event replay data, then verifying the corrected behavior with the replay data.
TODO:
Need to translate the event data into a unit test./new_microblock
payload, along with the subsequent confirmation or rejection from an anchor block from a/new_block
payload isn't well tested. It looks like the event replay data got accidentally wiped from the mainnet microblocks deployment, so we'll have to deploy this branch and let it run for a while to confirm no regressions.