-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Improve handling of unset StorageVersion
#13417
Conversation
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.
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.
Okay your approach is completely from what I used on rococo 😛
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.
Did you test it with the try-runtime CLI yet on a live network?
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.
Looks good. I’m still worried about the multi-block stuff, but since we can’t properly test it via try-runtime either it seems - makes no difference. The one scenario in which it could become annoying is when we have some CI check that would either fail try-runtime or we’d have to set the new StorageVersion before the storage has been fully migrated.
Just going to leave this concern here, perhaps we’ll get back to it when the solution is needed.
Ouch… https://substrate.stackexchange.com/questions/7396 |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
It works now on Polkadot. Did we fix that version mismatch in pallet |
on_chain_version, | ||
); | ||
|
||
return Err("On chain storage version set, while the pallet doesn't \ |
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.
Just one nit: you could collect all those errors in a vector and return them at the end. Then we can debug multiple erroneous pallets at once, like in Rococo.
Good point. Should have been done as part of paritytech/polkadot@ccffb73 @gupnik could you please open a pr for your migration to set the storage version to |
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
bot rebase |
Rebased |
* 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 <>
When a user is forgetting to set the storage version in a pallet and calls
current_storage_version
to compare it against theon_chain_storage_version
it will now fail to compile the code. Before the pallet macro just returnedStorageVersion::default()
forcurrent_storage_version
leading to potential issues with migrations. Besides that it also checks inpost_upgrade
that the pallet storage version was upgraded and thus, no migration was missed.Closes: #13062
Failing try-runtime tests
After this pr it can happen that
try-runtime
tests are failing, because pallets don't have the properStorageVersion
set on chain. This can either mean that a migration was missed or that a pallet was added after genesis and it was missed to set the storage version. To fix the later, it just requires a simple migration that does:After that
try-runtime
will be happy and everything should work.