Repair Rococo pallets

[ggwpez]

Some Rococo pallets suffer from mismatching versions between their code and storage.
Output of the preliminary version of this paritytech/substrate#13062:

Chain and code version mismatch for pallet Council: 0 != 4
Chain and code version mismatch for pallet TechnicalCommittee: 0 != 4
Chain and code version mismatch for pallet PhragmenElection: 0 != 4
Chain and code version mismatch for pallet TechnicalMembership: 0 != 4
Chain and code version mismatch for pallet Scheduler: 0 != 4
Chain and code version mismatch for pallet Tips: 0 != 4
Chain and code version mismatch for pallet NisCounterpartBalances: 0 != 1
Chain and code version mismatch for pallet ParasDisputes: 1 != 0
Chain and code version mismatch for pallet Crowdloan: 0 != 1

This probably comes from skipped runtimes and thereby skipped migrations in the upgrade process.
We need to double-check these pallets and then somehow fix them. Could be done by applying "re-deploy" migrations, or applying the missing migrations one by one. That is more of a pallet-by-pallet decision, since some of them have storage invariants which could have been broken.

Pallets:

• Council
• TechnicalCommittee
• PhragmenElection
• TechnicalMembership
• Scheduler
• Tips
• NisCounterpartBalances
• ParasDisputes: has a higher chain than code version, dont know how that happened 🤔.
• Crowdloan

[ggwpez]

Bounties is also broken.

[liamaharon]

Hey @ggwpez, I'm trying to determine the actual version of some pallets to identify if any need a real migrations (rather than just setting the version) are needed and have a question.

A version was added to pallet_collective 20 months ago, at the same time that the V4 migration was added: https://github.com/paritytech/substrate/pull/9115/files#diff-c9c139781d3a46e74bd99df5b95bfb6274b9c0deda846a5022971dfe155526bfR168

As noted in this issue, the storage version for Council in Rococo (and other collective pallets) is 0. Does this mean that Rococo's collective pallets are pre-V4? It seems unlikely, because Rococo's first block was finalized 385 days ago but the V4 migration (and version) was added to the pallet >600 days ago.

Is my assumption that #[pallet::storage_version(STORAGE_VERSION)] existing on a pallet at the time of chain initialisation means that an on-chain version will be initialised incorrect? If so, where is the initial on-chain version supposed to be initialised?

[ggwpez]

I am not sure how much effort we should invest here for a test-net.
Factually, nobody complained so far that stuff was broken. So it seems that the current state of things works "fine".
We may just go ahead and force-set all pallet versions and ignore the old storage, since nobody seems to miss the old data (which is now outdated anyway).

Do you think this is reasonable @bkchr ?

Is my assumption that #[pallet::storage_version(STORAGE_VERSION)] existing on a pallet at the time of chain initialisation means that an on-chain version will be initialised incorrect? If so, where is the initial on-chain version supposed to be initialised?

I am not sure, but think that before paritytech/substrate#13417, there was no bullet-proof way to ensure it.

[liamaharon]

Alright, well that makes my PR much easier :)

Will open one just bumping on-chain to match current for now.

[bkchr]

Do you think this is reasonable @bkchr ?

Sounds reasonable!

[liamaharon]

Fixed in paritytech/substrate#14174, #7251