-
Notifications
You must be signed in to change notification settings - Fork 790
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
Client: use same Cache Setup for normal and executeBlocks-triggered Execution #3063
Client: use same Cache Setup for normal and executeBlocks-triggered Execution #3063
Conversation
… from the original options to be passed, adopt StateManager usage
… when run with --executeBlocks flag
Codecov Report
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
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.
Small nits but looks great overall.
@acolytec3 thanks for the review 🙏, ok, have updated! |
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.
Left a couple of more comments on the docs. Feel free to take or leave them.
One more general question, do we ever actually copy the cache values over? I don't see that option anywhere in the code and our docs seem to indicate it's possible to do a copy where the state of the cache is actually preserved.
@acolytec3 ok, updated 🙂, ready for re-review! |
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
This PR aligns the cache setup for the client for "normal" execution along sync or standalone and re-execution with the
--executeBlocks
flag so that the StateManager and trie cache setups match the cache setup announced by client CLI, react on cache flag usage (especially trie cache) and generally allows for better cache behavior debugging (so that--executeBlocks
"mimics" the normal execution behavior and not somewhat behaves differently).Implementation is done by getting generally more flexible (with additional
shallowCopy()
method options), so that we but also users in general can choose if they want to have their shallow copy for rather short term or long term use.For trie I additionally generally generalized the options take in by using an options dict which replaces the plain keyPrefix parameter (still possible since not yet released). Then we can eventually add other options too there.
Open for review. 🙂