-
Notifications
You must be signed in to change notification settings - Fork 2.6k
OnInitialize must run in order of declaration in construct_runtime (not in reversed as currently) #6280
Comments
maybe this should be into substrate 2.0 |
maybe one solution is to fix it and allow to keep old behavior with an attribute in construct_runtime: construct_runtime!(
#[set_all_module_reversed_order]
pub enum Runtime where
Block = Block,
NodeBlock = node_primitives::Block,
UncheckedExtrinsic = UncheckedExtrinsic
{
...
}) |
I believe two of the consensus pallets' |
IMO we will want to have the same order for all hooks, including |
maybe we can use some on_finalize_requirement and on_initialize_requirement in hooks, those would return the required pallet to be executed before. enum HookRequirement {
PalletIndex(u32),
Misc([u8; 8]),
}
impl Hooks for Pallet {
fn on_finalize_requirement() -> Vec<HookRequirement> { ... }
} |
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. |
issue is still relevant |
Currently OnInitialize is run in the reversed order of their declaration in construct_runtime.
construct_runtime expand AllModules to:
and on_initialize for tuple is implemented using first and then second element.
The fix is:
But it needs tests and to make sure it doesn't break anything in kusama/polkadot.
Maybe this should be fixed with a flag in construct_runtime so it is opt-in for other chains.
The text was updated successfully, but these errors were encountered: