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>
Since the hash rules of this part of the `pallet_prefix/storage_prefix`
are always fixed, we can put the runtime calculation into compile time.
---
polkadot address: 15ouFh2SHpGbHtDPsJ6cXQfes9Cx1gEFnJJsJVqPGzBSTudr
---------
Co-authored-by: Juan <juangirini@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* 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
* Focus on correctness lints. This relies on a compiler patch that landed 8th July 2021.
If people are using an earlier version of the compiler everything will still work unless they try and run clippy.
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
* Record pallet indices in CallMetadata
* Resurrect PalletVersion infrastructure and rename as CrateVersion
* cargo fmt
* Add missing runtime generics to pallet struct
* Fix path to instance
* Fix test
* Fix UI test expectations
* Fix UI test expectations
* Move crate_version function to PalletInfoAccess
* Update UI test expectations
* Add crate_name method to PalletInfo
* Convert path to module name instead of exposing crate name
* cargo fmt
* Keep the double colons when constructing the module name
* Remove unused import
* Update UI test expectations
* Update frame/support/src/traits/metadata.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
* Update UI test expectations
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
* 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>
* Run cargo fmt on the whole code base
* Second run
* Add CI check
* Fix compilation
* More unnecessary braces
* Handle weights
* Use --all
* Use correct attributes...
* Fix UI tests
* AHHHHHHHHH
* 🤦
* Docs
* Fix compilation
* 🤷
* Please stop
* 🤦 x 2
* More
* make rustfmt.toml consistent with polkadot
Co-authored-by: André Silva <andrerfosilva@gmail.com>
* generate accessor to PalletInfo information on pallet placeholder
* remove unused
* use trait, and add tests
* less verbose doc
* add PalletInfoAccess to prelude for ease usage
Liam Aharon