-
Notifications
You must be signed in to change notification settings - Fork 227
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(cosmos): don't init controller before upgrade #8106
Conversation
Tip for reviewers: hide whitespace difference |
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 is simpler than what I had tried.
@JimLarson: @mhofman and I concluded that supporting non-restarting (dynamic?) software-upgrade plans isn't necessary at this time, and we can punt it until we actually need it. This PR's assertions will cause such code to fail rather than proceed confusedly.
// This will cause the swingset controller to init if it hadn't yet, passing | ||
// any upgrade plan or bootstrap flag when starting at an upgrade height | ||
swingset.ModuleName, |
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.
👍
case AG_COSMOS_INIT: { | ||
case ActionType.AG_COSMOS_INIT: { |
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.
❤️
b66b4b6
to
2e06f25
Compare
fix(cosmos): don't init controller before upgrade
fix(cosmos): don't init controller before upgrade
fix(cosmos): don't init controller before upgrade
fix(cosmos): don't init controller before upgrade
refs: #8060
Description
While testing upgrade handlers and migrations for #8031, I encountered an issue where the swingset controller was initialized before the migration starts. #8060 refactored some of this logic, but didn't fix this issue.
This PR moves the init step to be triggered by the swingset module, and add guards making sure the upgrade handler is executed before init.
It also consolidates the bootstrap into the init message, which will allow the JS side to have stronger assertions about the expected swing-store state when initializing.
Security Considerations
None
Scaling Considerations
None
Documentation Considerations
None, internal logic. Add some comments about the different use cases supported
Testing Considerations
The existing docker upgrade test should cover the new assertion, and any cosmic-swingset test already covers the bootstrap logic. Further tests will be added in the migration PR addressing #8031
Upgrade Considerations
None, this simply enforces what were the expected upgrade start flow.