Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Update contract multi-block migration #14313

Merged
merged 45 commits into from
Jun 20, 2023

Conversation

pgherveou
Copy link
Contributor

@pgherveou pgherveou commented Jun 6, 2023

Follow-up to #14045:

  • Update migration module docstring
  • Rename Migrate to MigrationStep
  • Update is_upgrade_supported
  • Ensure that we do as many migration steps as possible given the weight limit passed to on_idle

@pgherveou pgherveou requested a review from athei as a code owner June 6, 2023 21:58
@pgherveou pgherveou requested review from a team, agryaznov and juangirini June 6, 2023 21:58
Co-authored-by: Juan <juangirini@gmail.com>
Copy link
Contributor

@juangirini juangirini left a comment

Choose a reason for hiding this comment

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

Gotta love the docs

frame/contracts/src/lib.rs Outdated Show resolved Hide resolved
frame/contracts/src/lib.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration.rs Show resolved Hide resolved
@pgherveou pgherveou added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. labels Jun 8, 2023
@pgherveou
Copy link
Contributor Author

@agryaznov I think I got them all, thanks for going deep on this review and the previous one 🙏

Could you please address unresolved comments from the original PR here in this follow-up?

@pgherveou pgherveou requested a review from agryaznov June 13, 2023 08:01
Copy link
Contributor

@agryaznov agryaznov left a comment

Choose a reason for hiding this comment

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

Currently this

log::debug!(
target: LOG_TARGET,
"{}: Range supported {:?}, range requested {:?}",
<Pallet<T>>::name(),
T::Migrations::VERSION_RANGE,
(storage_version, target_version)
);

prints out a message like this

Contracts: Range supported (12, 12), range requested (StorageVersion(11), StorageVersion(12))

Which imo could cause a cognitive dissonance for a person not quite deep into the MBM implementation details (which I believe could be the most users of the pallet): "requested` (11,12), supported (12,12), but it's okay...".

Maybe it worth making it print supported range like (T::Migrations::VERSION_RANGE.0 - 1, T::Migrations::VERSION_RANGE)?

Or, even better, to print it in the same fashion as it was specified in the runtime config: "range requested/supported (12,)"

frame/contracts/src/benchmarking/mod.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration/v11.rs Show resolved Hide resolved
frame/contracts/src/lib.rs Show resolved Hide resolved
frame/contracts/src/lib.rs Show resolved Hide resolved
frame/contracts/src/migration.rs Outdated Show resolved Hide resolved
frame/contracts/src/migration/v10.rs Show resolved Hide resolved
frame/contracts/src/lib.rs Outdated Show resolved Hide resolved
match result {
// There is not enough weight to perform a migration, or make any progress, we
// just return the remaining weight.
NoMigrationPerformed | InProgress { steps_done: 0 } => return remaining_weight,
Copy link
Member

Choose a reason for hiding this comment

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

Isn't that the same as just break?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

well this case means that there might be a migration in progress, but we did not have enough gas to make any kind of progress, so you want to exit early here, are doing any work in this function is unsafe is there an actual migration going on.

Comment on lines -177 to +219
if in_storage == target {
return true
}
if in_storage > target {
return false
}

let (low, high) = Self::VERSION_RANGE;
let Some(first_supported) = low.checked_sub(1) else {
return false
};

in_storage >= first_supported && target == high
target == high && in_storage + 1 == low
Copy link
Member

Choose a reason for hiding this comment

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

What if no migration is needed and also none is provided? In this case it would return false and pre_upgrade will fail even though migrations will be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

then you should probably not include it at all in the runtime executive

Copy link
Member

Choose a reason for hiding this comment

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

As long as we can catch the case when somebody forgets to put it back in again this is fine. I suppose try-runtime will catch this missing migration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if we want to be lean and embed as little code as possible, we probably want to enforce it, I would be for leaving it like that and adding an explicit message in the pre_upgrade if storage_version == target_version

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does indeed, last time I tried, will test it again here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it is also only invoked in try_runtime, you will get away with just a warning if you were to run such a migration

if storage_version == latest_version {
log::warn!(
target: LOG_TARGET,
"{name}: No Migration performed storage_version = latest_version = {:?}",
&storage_version
);
return T::WeightInfo::on_runtime_upgrade_noop()
}

@pgherveou
Copy link
Contributor Author

bot merge

@paritytech-processbot paritytech-processbot bot merged commit 8bf628d into master Jun 20, 2023
@paritytech-processbot paritytech-processbot bot deleted the pg/more_migratinons_per_block branch June 20, 2023 13:16
nathanwhit pushed a commit to nathanwhit/substrate that referenced this pull request Jul 19, 2023
* move migrate sequence to config

* remove commented out code

* Update frame/contracts/src/lib.rs

Co-authored-by: PG Herveou <pgherveou@gmail.com>

* remove Migrations generic

* make runtime use noop migrations

* restrict is_upgrade_supported

* Update contract multi-block migration

Ensure that we do as many steps as possible given the weight limit passed to on_idle

* undo is_upgrade_supported change

* Update bin/node/runtime/src/lib.rs

Co-authored-by: PG Herveou <pgherveou@gmail.com>

* wip

* fix comment (paritytech#14316)

* fix test

* fix

* Update frame/contracts/src/migration.rs

Co-authored-by: Juan <juangirini@gmail.com>

* fix test doc

* Apply suggestions from code review

Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>

* Fix compilation with feature runtime-benchmarks

* fix example

* fix  cargo doc --document-private-items

* private links

* Remove dup comment

* add doc for MigrationInProgress

* PR review remove duplicate asserts

* simplify upper bound

* fix link

* typo

* typo

* no unwrap()

* correct log message

* missing

* fix typo

* PR comment

* Add example with single element tuple

* Improve migration message

* Update frame/contracts/src/benchmarking/mod.rs

Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>

* Update frame/contracts/src/migration.rs

Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>

* Update frame/contracts/src/migration.rs

Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>

* use saturating_accrue instead of +=

* add more doc

* Contracts: Better migration types (paritytech#14418)

* Add explicit error, if try-runtime runs a noop migration

* use mut remaining_weight

---------

Co-authored-by: Juan Girini <juangirini@gmail.com>
Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants