-
Notifications
You must be signed in to change notification settings - Fork 19
Rework migration and on runtime upgrade logic execution #1315
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
base: master
Are you sure you want to change the base?
Conversation
3323773 to
2cb6dc3
Compare
10f7009 to
ab80d9c
Compare
ab80d9c to
48a39c7
Compare
0af952a to
b78da82
Compare
crates/pallet-balanced-currency-swap-bridges-initializer/src/tests.rs
Outdated
Show resolved
Hide resolved
MOZGIII
left a comment
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.
Please explain the logic behind this change - in particular why alter all the pallets
Added to the description |
05b4304 to
c5d8330
Compare
|
We'd have to put this on hold for now, a I need to do more research on this and dig deeper to really conclude something propely; note there are no useless migrations, and, in principle, migrations are to be kept forever; unless there is a special certain cutoff date for them. |
Got it. The PR is not about avoiding having useless migrations, but to make the migrations itself more flexible. We can always have it at runtime level to keep it forever but control all migrations in one place. Btw, looking forward to doing more research on your side and discussing later. I just was inspired by the general logic of custom upgrades usage after researching substrate updates related to |
e14e9b8 to
9ff37a1
Compare
|
|
||
| // Do runtime upgrade hook. | ||
| v1::AllPalletsWithoutSystem::on_runtime_upgrade(); | ||
| // // Do runtime upgrade hook. |
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.
| // // Do runtime upgrade hook. | |
| // Do runtime upgrade hook. |
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.
PR Overview
This PR reworks the migration and runtime upgrade logic to avoid invoking upgrades for each pallet on every runtime upgrade. The key changes include dedicated OnRuntimeUpgrade implementations for migration (e.g. UpgradeInit, MigrationV0ToV1) and removal of redundant runtime hooks, along with updates to Cargo.toml dependency lists to support the new design.
Reviewed Changes
| File | Description |
|---|---|
| crates/pallet-dummy-precompiles-code/src/upgrade_init.rs | Introduces a dedicated runtime upgrade implementation for dummy precompiles |
| crates/pallet-erc20-support/src/migrations/v1.rs | Adds migration logic from version 0 to 1 with minor spelling corrections |
| crates/pallet-humanode-session/src/migrations/v1.rs | Updates migration logic and error messages with corrected version control text |
| crates/pallet-balanced-currency-swap-bridges-initializer/Cargo.toml | Updates Cargo.toml dependencies to include frame-executive features |
| crates/pallet-dummy-precompiles-code/Cargo.toml | Updates Cargo.toml dependencies to include frame-executive features |
| Other mock and lib files | Adjust runtime upgrade integration to use the new UpgradeInit implementations |
Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.
| } | ||
|
|
||
| if !not_created_precompiles.is_empty() { | ||
| return Err("precompiles not created properly: {:not_created_precompiles}"); |
Copilot
AI
Mar 4, 2025
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 error message uses a placeholder without interpolation. Consider using a formatted string (e.g. via format!) to include the relevant data.
| return Err("precompiles not created properly: {:not_created_precompiles}"); | |
| return Err(format!("precompiles not created properly: {:?}", not_created_precompiles).as_str()); |
| let mut weight: Weight = T::DbWeight::get().reads(1); | ||
|
|
||
| if onchain_version != 0 { | ||
| info!("Not at version 0, nothing to do. This migrarion probably should be removed"); |
Copilot
AI
Mar 4, 2025
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.
Spelling error in 'migrarion'; please change it to 'migration'.
| info!("Not at version 0, nothing to do. This migrarion probably should be removed"); | |
| info!("Not at version 0, nothing to do. This migration probably should be removed"); |
| if onchain == 1 { | ||
| info!("Already at version 1, nothing to do"); | ||
| if onchain != 0 { | ||
| info!("Not at version 0, nothing to do. This migrarion probably should be removed"); |
Copilot
AI
Mar 4, 2025
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.
Spelling error in 'migrarion'; please update it to 'migration'.
| info!("Not at version 0, nothing to do. This migrarion probably should be removed"); | |
| info!("Not at version 0, nothing to do. This migration probably should be removed"); |
|
@MOZGIII the idea is still relevant ? Or we would like to leave migration logic at our pallets as it is In case, it's relevant, I'll rebase over latest master |
|
This should be a part of one of the substrate upgrades, but it is not explicitly marked as such, and doesn't contain the necessary context for when a similar change in the thought was introduced to substrate.
This is, really, very simple. We want to follow the lead of the upstream here. So all that's necessary to decide is the context from above. Please add it to the PR description, and it will be quite trivial to make a decision. Most likely we'll go with the upgrade. If it's not yet what the substrate was doing - we'll postpone it. If this is something that had to be included with our current substrate version - let's apply it. |
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 changes here are technically fine - but there is still a question of whether we want to switch to this approach or not.
See #1315 (comment)
The main goal of this PR is to avoid running runtime upgrade execution for each pallet on each runtime upgrade. The idea is taken from
substrateandpolkadot-sdkapproach to use an ability passing actual migration at the runtime itself.There are introduced separate objects responsible for runtime upgrade logic that implement
OnRuntimeUpgradeto be passed athumanode-runtimetoExecutivelike: