-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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: chain: put tipsetkey upon expansion of tipset #10069
Conversation
@raulk will be contributing a test <3 |
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.
There's a case to be made that the key persistence belongs inside of expandTipSet to match the fact that its buried inside PersistTipSet in the non expanded case.
But this LGTM
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.
Honestly this seems like a workaround since we're not correcting the fact that we we are persisting tipset CIDs for unexpanded tipsets. However, if the Lotus team is happy with this solution (versus what we had in the past before this refactor was made, which worked better IMO and was cleaner IIRC), then let's go forward.
Just to check: this tipset CID will be correctly handled by the splitstore, right?
@raulk We can drop the persistence of the unexpanded tipsets. I only have it there for redundancy / to cover our bases. I can also definitely go back to what we had before, but I'm not convinced it was correct (from PR description):
I would like to understand this a bit before merging to make sure we know what we're doing and get it right this time.
Yes, anything in our main chain will be protected, TSKs that aren't in our main chain will get GCed. |
Confirmed that this patch fixes the issue with live syncing. After bringing up my node to speed with Hyperspace + letting it run for a few minutes, all block hashes are consistent as reported by the tool in #10060:
|
@arajasek unfortunately I don't have the bandwidth to go digging to find an explanation now. However, I can say that the previous version of the code had been running for months in Wallaby without issues. I can't spend the time now to re-grok the Lotus sync code to understand if there'd be any missing gaps if we went back to the original version, so let's merge this and open a TODO to clean this up later? |
Related Issues
Fixes #10061
Proposed Changes
The bug, introduced in #9904, caused us to not put the "expanded" tipsetkey in our blockstore. We're now putting the expanded TSK.
I'm a little confused about how things were working before 9904. AFAIC tell we had the opposite bug before 9904 -- we only put the TSK when we were taking a new heaviest tipset, which does not happen during "catch-up" sync. I suspect we were missing all TSKs during catch-up sync in the previous version.
Additional Info
Checklist
Before you mark the PR ready for review, please make sure that:
<PR type>: <area>: <change being made>
fix: mempool: Introduce a cache for valid signatures
PR type
: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, testarea
, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps