- Nov 28, 2023
-
-
gupnik authored
Step in https://github.com/paritytech/polkadot-sdk/issues/171 This PR adds `derive_impl` on all `frame_system` config impls for mock runtimes. The overridden configs are maintained as of now to ensure minimal changes. --------- Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-
- Nov 10, 2023
-
-
Liam Aharon authored
As suggested by @ggwpez (https://github.com/paritytech/polkadot-sdk/pull/2142#discussion_r1388145872), remove the `VersionChecked` prefix from version checked migrations (but leave `VersionUnchecked` prefixes) --------- Co-authored-by: command-bot <>
-
- Oct 24, 2023
-
-
Kian Paimani authored
closes https://github.com/paritytech/polkadot-sdk/issues/1882 ## Breaking Changes This PR introduces a new item to `pallet_balances::Config`: ```diff trait Config { ++ type RuntimeFreezeReasons; } ``` This value is only used to check it against `type MaxFreeze`. A similar check has been added for `MaxHolds` against `RuntimeHoldReasons`, which is already given to `pallet_balances`. In all contexts, you should pass the real `RuntimeFreezeReasons` generated by `construct_runtime` to `type RuntimeFreezeReasons`. Passing `()` would also work, but it would imply that the runtime uses no freezes at all. --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-
- Oct 15, 2023
-
-
Daan van der Plas authored
The runtime code of a parachain can be replaced on the relay-chain via: [cumulus]: [enact_authorized_upgrade](https://github.com/paritytech/polkadot-sdk/blob/1a38d6d6be42b30e8be3ffccec75a4ec995fef9d/cumulus/pallets/parachain-system/src/lib.rs#L661); this is used for a runtime upgrade when a parachain is not bricked. [polkadot] (these are used when a parachain is bricked): - [force_set_current_code](https://github.com/paritytech/polkadot-sdk/blob/1a38d6d6be42b30e8be3ffccec75a4ec995fef9d/polkadot/runtime/parachains/src/paras/mod.rs#L823): immediately changes the runtime code of a given para without a pvf check (root). - [force_schedule_code_upgrade](https://github.com/paritytech/polkadot-sdk/blob/1a38d6d6be42b30e8be3ffccec75a4ec995fef9d/polkadot/runtime/parachains/src/paras/mod.rs#L864): schedules a change to the runtime code of a given para including a pvf check of the new code (root). - [schedule_code_upgrade](https://github.com/paritytech/polkadot-sdk/blob/1a38d6d6be42b30e8be3ffccec75a4ec995fef9d/polkadot/runtime/common/src/paras_registrar.rs#L395): schedules a change to the runtime code of a given para including a pvf check of the new code. Besides root, the parachain or parachain manager can call this extrinsic given that the parachain is unlocked. Polkadot signals a parachain to be ready for a runtime upgrade through the [GoAhead](https://github.com/paritytech/polkadot-sdk/blob/e49493442a9377be9344c06a4990e17423783d41/polkadot/primitives/src/v5/mod.rs#L1229) signal. When in cumulus `enact_authorized_upgrade` is executed, the same underlying helper function of `force_schedule_code_upgrade` & `schedule_code_upgrade`: [schedule_code_upgrade](https://github.com/paritytech/polkadot/blob/09b61286da11921a3dda0a8e4015ceb9ef9cffca/runtime/parachains/src/paras/mod.rs#L1778), is called on the relay-chain, which sets the `GoAhead` signal (if the pvf is accepted). If Cumulus receives the `GoAhead` signal from polkadot without having the `PendingValidationCode` ready, it will panic ([ref](https://github.com/paritytech/polkadot/pull/7412)). For `enact_authorized_upgrade` we know for sure the `PendingValidationCode` is set. On the contrary, for `force_schedule_code_upgrade` & `schedule_code_upgrade` this is not the case. This PR includes a flag such that the `GoAhead` signal will only be set when a runtime upgrade is enacted by the parachain (`enact_authorized_upgrade`). additional info: https://github.com/paritytech/polkadot/pull/7412 Closes #641 --------- Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
-
- Sep 13, 2023
-
-
Liam Aharon authored
`VersionedMigration` has become somewhat widely used for handling version bumps in migrations the last few months. It is currently behind the `experimental` feature flag, requiring every pallet that writes a new migration with version bumps to set up the `experimental` flag in their own Cargo.tomls, and also for every runtime using these pallets to explicitly enable the `experimental` flag for each pallet. This is becoming quite verbose, and I can only see the number of pallets requiring the experimental flag increasing for no other reason than using what has become a commonly used feature. Additionally, I'm writing migration docs and would like to avoid stepping through how to use the `experimental` feature to get `VersionedMigration` working. Since the feature has been used in production for some time now without any reported issues, is becoming commonly used and ready to advertise in docs, I feel this is a good time to make it non-experimental.
-
- Sep 06, 2023
-
-
Xiliang Chen authored
* rfc14 * Update polkadot/runtime/common/src/paras_registrar/mod.rs Co-authored-by: Bastian Köcher <[email protected]> * Update polkadot/runtime/common/src/paras_registrar/mod.rs Co-authored-by: Bastian Köcher <[email protected]> * Update polkadot/runtime/common/src/paras_registrar/mod.rs Co-authored-by: Bastian Köcher <[email protected]> * fmt * fix * Update polkadot/runtime/common/src/paras_registrar/migration.rs Co-authored-by: Oliver Tale-Yazdi <[email protected]> * fmt * 2224 is unlocked * update migration list * update comment * use VersionedMigration --------- Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-