This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Add Version Checks on Para Upgrade#2261
Merged
paritytech-processbot[bot] merged 4 commits intomasterfrom Mar 2, 2023
Merged
Conversation
bkchr
approved these changes
Mar 1, 2023
Co-authored-by: Bastian Köcher <git@kchr.de>
gilescope
approved these changes
Mar 1, 2023
ruseinov
approved these changes
Mar 1, 2023
Contributor
Author
|
bot merge |
Contributor
|
Can we have some scary labels to ensure this PR is getting attentions by parachain teams? It is a breaking change and will impact scripts related to runtime upgrade. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds checks to ensure that the spec version is increasing and that the spec name is the same. This will prevent accidentally upgrading a parachain to a different runtime.
Migration
Although this changes storage, I did not increase the storage version or provide a migration. The reason is that the upgrade itself will
killthe affected storage item, and the next time an upgrade is authorized, the new type will be written. But this will break any front ends that show authorized upgrades, so let me know if I should bump the storage version for this.Transaction Version
Unfortunately breaks it, although it's a Root call. Could also add a new function
authorize_upgrade_without_checksas an alternative.