Original PR https://github.com/paritytech/substrate/pull/14641
---
Closes https://github.com/paritytech/polkadot-sdk/issues/109
### Problem
Quoting from the above issue:
> When adding a pallet to chain after genesis we currently don't set the
StorageVersion. So, when calling on_chain_storage_version it returns 0
while the pallet is maybe already at storage version 9 when it was added
to the chain. This could lead to issues when running migrations.
### Solution
- Create a new trait `BeforeAllRuntimeMigrations` with a single method
`fn before_all_runtime_migrations() -> Weight` trait with a noop default
implementation
- Modify `Executive` to call
`BeforeAllRuntimeMigrations::before_all_runtime_migrations` for all
pallets before running any other hooks
- Implement `BeforeAllRuntimeMigrations` in the pallet proc macro to
initialize the on-chain version to the current pallet version if the
pallet has no storage set (indicating it has been recently added to the
runtime and needs to have its version initialised).
### Other changes in this PR
- Abstracted repeated boilerplate to access the `pallet_name` in the
pallet expand proc macro.
### FAQ
#### Why create a new hook instead of adding this logic to the pallet
`pre_upgrade`?
`Executive` currently runs `COnRuntimeUpgrade` (custom migrations)
before `AllPalletsWithSystem` migrations. We need versions to be
initialized before the `COnRuntimeUpgrade` migrations are run, because
`COnRuntimeUpgrade` migrations may use the on-chain version for critical
logic. e.g. `VersionedRuntimeUpgrade` uses it to decide whether or not
to execute.
We cannot reorder `COnRuntimeUpgrade` and `AllPalletsWithSystem` so
`AllPalletsWithSystem` runs first, because `AllPalletsWithSystem` have
some logic in their `post_upgrade` hooks to verify that the on-chain
version and current pallet version match. A common use case of
`COnRuntimeUpgrade` migrations is to perform a migration which will
result in the versions matching, so if they were reordered these
`post_upgrade` checks would fail.
#### Why init the on-chain version for pallets without a current storage
version?
We must init the on-chain version for pallets even if they don't have a
defined storage version so if there is a future version bump, the
on-chain version is not automatically set to that new version without a
proper migration.
e.g. bad scenario:
1. A pallet with no 'current version' is added to the runtime
2. Later, the pallet is upgraded with the 'current version' getting set
to 1 and a migration is added to Executive Migrations to migrate the
storage from 0 to 1
a. Runtime upgrade occurs
b. `before_all` hook initializes the on-chain version to 1
c. `on_runtime_upgrade` of the migration executes, and sees the on-chain
version is already 1 therefore think storage is already migrated and
does not execute the storage migration
Now, on-chain version is 1 but storage is still at version 0.
By always initializing the on-chain version when the pallet is added to
the runtime we avoid that scenario.
---------
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
Closes https://github.com/paritytech/polkadot-sdk/issues/1916
Changes:
- Trivially wrap the migration into a version migration to enforce
idempotency.
- Opinionated logging nits
@liamaharon maybe we can add a check to the `try-runtime-cli` that
migrations are idempotent? It should be possible to check that the
storage root is identical after executing a second time (and that it
does not panic like it did here 😆).
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
`VersionedMigration` has become somewhat widely used for handling
version bumps in migrations the last few months.
It is currently behind the `experimental` feature flag, requiring every
pallet that writes a new migration with version bumps to set up the
`experimental` flag in their own Cargo.tomls, and also for every runtime
using these pallets to explicitly enable the `experimental` flag for
each pallet.
This is becoming quite verbose, and I can only see the number of pallets
requiring the experimental flag increasing for no other reason than
using what has become a commonly used feature.
Additionally, I'm writing migration docs and would like to avoid
stepping through how to use the `experimental` feature to get
`VersionedMigration` working.
Since the feature has been used in production for some time now without
any reported issues, is becoming commonly used and ready to advertise in
docs, I feel this is a good time to make it non-experimental.
* Improve handling of unset `StorageVersion`
When a user is forgetting to set the storage version in a pallet and calls
`current_storage_version` to compare it against the `on_chain_storage_version` it will now fail to
compile the code. Before the pallet macro just returned `StorageVersion::default()` for
`current_storage_version` leading to potential issues with migrations. Besides that it also checks
in `post_upgrade` that the pallet storage version was upgraded and thus, no migration was missed.
* Use correct `Cargo.lock`
* Fixes
* Fix test
* Update frame/support/test/tests/pallet.rs
* Ensure we don't set a storage version when the pallet is missing the attribute
* Fix merge conflict
* Update frame/support/procedural/src/pallet/expand/hooks.rs
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
* Update frame/support/procedural/src/pallet/expand/hooks.rs
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
* Fix compilation
* Do not run everything with `try-runtime`
* Fix test
* Apply suggestions from code review
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix `no-metadata-docs`
---------
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: parity-processbot <>
* Change copyright year to 2023 from 2022
* Fix incorrect update of copyright year
* Remove years from copy right header
* Fix remaining files
* Fix typo in a header and remove update-copyright.sh
* update api
* update
* remove unused
* remove `one` api
* fix unused
* fmt
* add saturating accrue
* remove `Weight::new()`
* use some macros
* div makes no sense
* Update weight_v2.rs
* missed some
* more patch
* fixes
* more fixes
* more fix
* more fix
* Update frame/support/src/weights/weight_v2.rs
* not needed
* fix weight file
* Move `PalletVersion` away from the crate version
Before this pr, `PalletVersion` was referring to the crate version that
hosted the pallet. This pr introduces a custom `package.metadata.frame`
section in the `Cargo.toml` that can contain a `pallet-version` key
value pair. While the value is expected to be a valid u16. If this
key/value pair isn't given, the version is set to 1.
It also changes the `PalletVersion` declaration. We now only have one
`u16` that represents the version. Not a major/minor/patch version. As
the old `PalletVersion` was starting with the `u16` major, decoding the
old values will work.
* Overhaul the entire implementation
- Drop PalletVersion
- Introduce StorageVersion
- StorageVersion needs to be set in the crate and set for the macros
- Added migration
* Fix migrations
* Review feedback
* Remove unneeded dep
* remove pub consts
* Brings back logging and implements `GetStorageVersion`
* Return weight from migration
* Fmt and remove unused import
* Update frame/support/src/dispatch.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
* Update frame/support/src/traits/metadata.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Liam Aharon