Encointer check-migration on polkadot-sdk@1.6.0 bump fails

[bkontur]

PR: bkontur#4
Failed job: https://github.com/bkontur/runtimes/actions/runs/8048060879/job/21978599251?pr=4

[2024-02-26T11:28:55Z ERROR runtime::executive] `try_decode_entire_state` failed with 1 errors
[2024-02-26T11:28:55Z ERROR runtime::executive] - 0. error: `ParachainSystem::HostConfiguration` key `0x45323df7cc47150b3930e2666b0aa313c522231880238a0c56021b8744a00743` is undecodable
[2024-02-26T11:28:55Z ERROR runtime] panicked at /home/runner/work/runtimes/runtimes/system-parachains/encointer/src/lib.rs:952:65:
    called `Result::unwrap()` on an `Err` value: Other("`try_decode_entire_state` failed")

Actual Encoiner parachain_system::HostConfiguration (V5 version):

parachainSystem.hostConfiguration: Option<PolkadotPrimitivesV5AbridgedHostConfiguration>

{
  maxCodeSize: 3,145,728
  maxHeadDataSize: 20,480
  maxUpwardQueueCount: 699,050
  maxUpwardQueueSize: 4,194,304
  maxUpwardMessageSize: 65,531
  maxUpwardMessageNumPerCandidate: 128
  hrmpMaxMessageNumPerCandidate: 10
  validationUpgradeCooldown: 3,600
  validationUpgradeDelay: 600
}

Other parachains live, using v6, e.g,. Polkadot AssetHub:

parachainSystem.hostConfiguration: Option<PolkadotPrimitivesV6AbridgedHostConfiguration>

{
  maxCodeSize: 3,145,728
  maxHeadDataSize: 20,480
  maxUpwardQueueCount: 174,762
  maxUpwardQueueSize: 1,048,576
  maxUpwardMessageSize: 65,531
  maxUpwardMessageNumPerCandidate: 16
  hrmpMaxMessageNumPerCandidate: 10
  validationUpgradeCooldown: 14,400
  validationUpgradeDelay: 600
  asyncBackingParams: {
    maxCandidateDepth: 0
    allowedAncestryLen: 0
  }
}

[bkontur]

@ggwpez @liamaharon any ideas? Missing some older migration? My guess is that asyncBackingParams causes that problem, wdyt?

[bkontur]

cc: @brenzi

[brenzi]

my guess is this can be safely ignored because that storage is written to upon every block: See @bkchr 's answer here
https://substrate.stackexchange.com/questions/10986/runtime-upgrade-for-parachainsystemhostconfiguration

[bkontur]

Ok, cool, thank you. Anyway, to write that kind of migration should be easy.

So if we are ok, that the pipeline for Encointer check-migrations won't work for main or release tag until enacted, then we can close this and merge bkontur#4 to the 1.6.0 bump.

[brenzi]

As the error is out of our scope and well-understood, I think we can safely be ok with that without wasting time on a migration (even if simple)

[bkontur]

ok, closing, at least we know about this issue.

[ggwpez]

There is actually also a warning being printed:
WARN runtime::fix::scheduler::migration] skipping v0 to v4 migration: executed on wrong storage version.Expected version < 3, found StorageVersion(4)

Is this expected @brenzi ? eg https://github.com/polkadot-fellows/runtimes/actions/runs/8051812338/job/21990579726?pr=159

[brenzi]

We introduced a hack to fix uninitialized storage versions. now that the sdk takes care of that with 1.6.0, that would no longer be necessary. Doesn't hurt though and all migrations can be removed after the next upgrade anyway. I'd vouch for ignoring this warning