Skip to content

Conversation

@dmitrylavrenov
Copy link
Contributor

@dmitrylavrenov dmitrylavrenov commented Nov 1, 2024

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 substrate and polkadot-sdk approach to use an ability passing actual migration at the runtime itself.

There are introduced separate objects responsible for runtime upgrade logic that implement OnRuntimeUpgrade to be passed at humanode-runtime to Executive like:

/// Executive: handles dispatch to the various modules.
pub type Executive = frame_executive::Executive<
    Runtime,
    Block,
     frame_system::ChainContext<Runtime>,
     Runtime,
     AllPalletsWithSystem,
     (
         init_storage_version::InitStorageVersion<DummyPrecompilesCode, Runtime>,
         init_storage_version::InitStorageVersion<BalancedCurrencySwapBridgesInitializer, Runtime>,
     ),
 >;

@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 2 times, most recently from 3323773 to 2cb6dc3 Compare November 1, 2024 12:42
@dmitrylavrenov dmitrylavrenov changed the title Rework migration logic Rework migration and on runtime upgrade logic execution Nov 1, 2024
@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 9 times, most recently from 10f7009 to ab80d9c Compare November 7, 2024 10:25
@dmitrylavrenov dmitrylavrenov changed the base branch from master to imporve-runtime-logs November 7, 2024 10:25
@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 2 times, most recently from ab80d9c to 48a39c7 Compare November 7, 2024 15:09
@dmitrylavrenov dmitrylavrenov changed the base branch from imporve-runtime-logs to master November 7, 2024 15:09
@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 6 times, most recently from 0af952a to b78da82 Compare November 8, 2024 12:41
@dmitrylavrenov dmitrylavrenov marked this pull request as ready for review November 8, 2024 12:44
Copy link
Contributor

@MOZGIII MOZGIII left a 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

@dmitrylavrenov
Copy link
Contributor Author

Please explain the logic behind this change - in particular why alter all the pallets

Added to the description

@dmitrylavrenov dmitrylavrenov marked this pull request as ready for review November 21, 2024 12:53
@MOZGIII
Copy link
Contributor

MOZGIII commented Nov 21, 2024

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.

@dmitrylavrenov
Copy link
Contributor Author

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 polkadot-v0.9.43.


// Do runtime upgrade hook.
v1::AllPalletsWithoutSystem::on_runtime_upgrade();
// // Do runtime upgrade hook.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// // Do runtime upgrade hook.
// Do runtime upgrade hook.

@MOZGIII MOZGIII requested a review from Copilot March 4, 2025 21:45
Copy link

Copilot AI left a 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}");
Copy link

Copilot AI Mar 4, 2025

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.

Suggested change
return Err("precompiles not created properly: {:not_created_precompiles}");
return Err(format!("precompiles not created properly: {:?}", not_created_precompiles).as_str());

Copilot uses AI. Check for mistakes.
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");
Copy link

Copilot AI Mar 4, 2025

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'.

Suggested change
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");

Copilot uses AI. Check for mistakes.
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");
Copy link

Copilot AI Mar 4, 2025

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'.

Suggested change
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");

Copilot uses AI. Check for mistakes.
@dmitrylavrenov
Copy link
Contributor Author

dmitrylavrenov commented Mar 5, 2025

@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

@MOZGIII
Copy link
Contributor

MOZGIII commented Apr 20, 2025

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.

the idea is still relevant ? Or we would like to leave migration logic at our pallets as it is

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.

Copy link
Contributor

@MOZGIII MOZGIII left a 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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants