-
Notifications
You must be signed in to change notification settings - Fork 159
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: don't GC manifests #4959
fix: don't GC manifests #4959
Conversation
Follow-up issue - create common helpers to use for migrations and also for DB operations. |
Let's hold off merging and releasing until the network upgrade on the mainnet (Nov 20th) to reduce chance of potential issues. |
@@ -124,6 +125,19 @@ where | |||
} | |||
} | |||
|
|||
impl<ReaderT> PersistentStore for AnyCar<ReaderT> |
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.
I feel it would be less error-prone to make Blockstore
trait persistent by default and have a GarbageCollectableStore
trait for storing blockchain data. Currently, ppl have to interpret Blockstore
as GarbageCollectableStore
to avoid mistakes which is counter-intuitive. What do you think?
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.
We can create an issue for that and we’ll address it as prioritized. It’s out of scope for this PR, I have already created an issue to generalize different stores a bit more to be able to rely on tests for different database types better.
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.
I’m also not sure that making Blockstore persistent by default is a good idea as the use-cases for persistent storage are pretty limited at the moment.
It seems our default use-case is garbage-collected, so having persistent storage as an add-on makes more sense. I do agree that in general case this would be counter-intuitive.
let depth = 5 as ChainEpochDelta; | ||
let current_epoch = 0 as ChainEpochDelta; | ||
|
||
let tester = GCTester::new(); |
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.
Shall we test both MemoryDB
and ParityDB
?
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.
ParityDB is tricky to test, there is an issue for that. Therefore it has been tested manually.
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.
The main issue there is that deletes are not propagating immediately, so unit testing it reliably is not currently possible.
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.
actually, no issue. creating one
// garbage collected. Until this is fixed, the GC has to be disabled. | ||
// Tracking issue: https://github.com/ChainSafe/forest/issues/4926 | ||
// if !opts.no_gc { | ||
if false { |
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.
Would love to see GC being manually triggered in at least one of the CI tests. Could you create a tracking issue if it cannot land in this PR?
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 is an issue for manual gc.
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.
@hanabi1224 I've created some issues and linked others to address the comments to this PR:
|
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. It'd be great to have @lemmih making a final review as well.
we can do this retroactively I guess, if anything pops-up - can be fixed in the next iteration. |
Summary of changes
Changes introduced in this pull request:
Reference issue to close (if applicable)
Closes #4926
Other information and links
The actors are found fine after several GC rounds, so this is confirmed. Also, the migration now works as intended.
Manual testing:
Several GC runs prior to state migration:
There are of course other errors that have to do with modifying the state migration epoch, but no bundle retrieval issues, I have also tested this before the
persistent
fix and it failed miserably trying to retrieve those from the DB.Change checklist