Relay failing to validate para block after parachain runtime Upgrade: Digest item must match that calculated

[crystalin]

Doing a parachain runtime upgrade can fail depending on how it is executed.
Those scenarios are run using polkadot-v9.3 branches.

The error message appears on the relaychain validator:

2021-06-05 04:19:24  panicked at 'Digest item must match that calculated.', /home/test/.cargo/git/checkouts/substrate-7e08433d4c370a21/85fa0ab/frame/executive/src/lib.rs:456:13

Our setCode is defined as:

type OnSetCode = cumulus_pallet_parachain_system::ParachainSetCode<Self>;

Scenario 1:

• Perform sudo.sudo => parachainSystem.authorizeUpgrade
• Perform sudo.sudo => parachainSystem.enactAuthorizedUpgrade
• ✅ parachain upgraded, producing blocks, relay including parachain blocks

Scenario 2:

• Perform sudo.sudo => system.setCode
• ❌parachain upgraded, producing blocks, relay refusing to validate parachain blocks: Digest item must match that calculated

Scenario 3:

• Perform sudo.sudo => utility.batch [parachainSystem.authorizeUpgrade, parachainSystem.enactAuthorizedUpgrade]
• ✅ parachain upgraded, producing blocks, relay including parachain blocks

Scenario 4:

• Perform democracy.preimage => utility.batch [parachainSystem.authorizeUpgrade, parachainSystem.enactAuthorizedUpgrade]
• Perform democracy.propose
• Second + Vote
• ❌parachain upgraded, producing blocks, relay refusing to validate parachain blocks: Digest item must match that calculated

[JoshOrndorff]

@bckchr pointed out in element that we need this macro. Thanks for the tip!

cumulus/polkadot-parachains/rococo-runtime/src/lib.rs

Line 79 in 7ffb205

#[sp_version::runtime_version]

This may be the underlying cause.

[crystalin]

Thank you @JoshOrndorff , this solves the Scenario 2 of using the sudo.sudo => system.setCode scenarion, but doesn't solve the democracy one.

[bkchr]

"Hijacking" this issue.

The problem is that democracy or better scheduler calls the autorizeUpgrade or setCode calls before the inherent data is set. This is not allowed because we need to ensure that upgrades are currently allowed. The solution is to this problem is to fix in Substrate the order when stuff like scheduler is applying stuff to happen after the inherents. This should be doable after: paritytech/substrate#10128