- Feb 16, 2024
-
-
georgepisaltu authored
Fixes #3014 This PR adds retry mechanics to `pallet-scheduler`, as described in the issue above. Users can now set a retry configuration for a task so that, in case its scheduled run fails, it will be retried after a number of blocks, for a specified number of times or until it succeeds. If a retried task runs successfully before running out of retries, its remaining retry counter will be reset to the initial value. If a retried task runs out of retries, it will be removed from the schedule. Tasks which need to be scheduled for a retry are still subject to weight metering and agenda space, same as a regular task. Periodic tasks will have their periodic schedule put on hold while the task is retrying. --------- Signed-off-by: georgepisaltu <[email protected]> Co-authored-by: command-bot <>
-
- Jan 31, 2024
-
-
Branislav Kontur authored
[frame] `#[pallet::composite_enum]` improved variant count handling + removed `pallet_balances`'s `MaxHolds` config (#2657) I started this investigation/issue based on @liamaharon question [here](https://github.com/paritytech/polkadot-sdk/pull/1801#discussion_r1410452499). ## Problem The `pallet_balances` integrity test should correctly detect that the runtime has correct distinct `HoldReasons` variant count. I assume the same situation exists for RuntimeFreezeReason. It is not a critical problem, if we set `MaxHolds` with a sufficiently large value, everything should be ok. However, in this case, the integrity_test check becomes less useful. **Situation for "any" runtime:** - `HoldReason` enums from different pallets: ```rust /// from pallet_nis #[pallet::composite_enum] pub enum HoldReason { NftReceipt, } /// from pallet_preimage #[pallet::composite_enum] pub enum HoldReason { Preimage, } // from pallet_state-trie-migration #[pallet::composite_enum] pub enum HoldReason { SlashForContinueMigrate, SlashForMigrateCustomTop, SlashForMigrateCustomChild, } ``` - generated `RuntimeHoldReason` enum looks like: ```rust pub enum RuntimeHoldReason { #[codec(index = 32u8)] Preimage(pallet_preimage::HoldReason), #[codec(index = 38u8)] Nis(pallet_nis::HoldReason), #[codec(index = 42u8)] StateTrieMigration(pallet_state_trie_migration::HoldReason), } ``` - composite enum `RuntimeHoldReason` variant count is detected as `3` - we set `type MaxHolds = ConstU32<3>` - `pallet_balances::integrity_test` is ok with `3`(at least 3) However, the real problem can occur in a live runtime where some functionality might stop working. This is due to a total of 5 distinct hold reasons (for pallets with multi-instance support, it is even more), and not all of them can be used because of an incorrect `MaxHolds`, which is deemed acceptable according to the `integrity_test`: ``` // pseudo-code - if we try to call all of these: T::Currency::hold(&pallet_nis::HoldReason::NftReceipt.into(), &nft_owner, deposit)?; T::Currency::hold(&pallet_preimage::HoldReason::Preimage.into(), &nft_owner, deposit)?; T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForContinueMigrate.into(), &nft_owner, deposit)?; // With `type MaxHolds = ConstU32<3>` these two will fail T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomTop.into(), &nft_owner, deposit)?; T::Currency::hold(&pallet_state_trie_migration::HoldReason::SlashForMigrateCustomChild.into(), &nft_owner, deposit)?; ``` ## Solutions A macro `#[pallet::*]` expansion is extended of `VariantCount` implementation for the `#[pallet::composite_enum]` enum type. This expansion generates the `VariantCount` implementation for pallets' `HoldReason`, `FreezeReason`, `LockId`, and `SlashReason`. Enum variants must be plain enum values without fields to ensure a deterministic count. The composite runtime enum, `RuntimeHoldReason` and `RuntimeFreezeReason`, now sets `VariantCount::VARIANT_COUNT` as the sum of pallets' enum `VariantCount::VARIANT_COUNT`: ```rust #[frame_support::pallet(dev_mode)] mod module_single_instance { #[pallet::composite_enum] pub enum HoldReason { ModuleSingleInstanceReason1, ModuleSingleInstanceReason2, } ... } #[frame_support::pallet(dev_mode)] mod module_multi_instance { #[pallet::composite_enum] pub enum HoldReason<I: 'static = ()> { ModuleMultiInstanceReason1, ModuleMultiInstanceReason2, ModuleMultiInstanceReason3, } ... } impl self::sp_api_hidden_includes_construct_runtime::hidden_include::traits::VariantCount for RuntimeHoldReason { const VARIANT_COUNT: u32 = 0 + module_single_instance::HoldReason::VARIANT_COUNT + module_multi_instance::HoldReason::<module_multi_instance::Instance1>::VARIANT_COUNT + module_multi_instance::HoldReason::<module_multi_instance::Instance2>::VARIANT_COUNT + module_multi_instance::HoldReason::<module_multi_instance::Instance3>::VARIANT_COUNT; } ``` In addition, `MaxHolds` is removed (as suggested [here](https://github.com/paritytech/polkadot-sdk/pull/2657#discussion_r1443324573)) from `pallet_balances`, and its `Holds` are now bounded to `RuntimeHoldReason::VARIANT_COUNT`. Therefore, there is no need to let the runtime specify `MaxHolds`. ## For reviewers Relevant changes can be found here: - `substrate/frame/support/procedural/src/lib.rs` - `substrate/frame/support/procedural/src/pallet/parse/composite.rs` - `substrate/frame/support/procedural/src/pallet/expand/composite.rs` - `substrate/frame/support/procedural/src/construct_runtime/expand/composite_helper.rs` - `substrate/frame/support/procedural/src/construct_runtime/expand/hold_reason.rs` - `substrate/frame/support/procedural/src/construct_runtime/expand/freeze_reason.rs` - `substrate/frame/support/src/traits/misc.rs` And the rest of the files is just about removed `MaxHolds` from `pallet_balances` ## Next steps Do the same for `MaxFreezes` https://github.com/paritytech/polkadot-sdk/issues/2997 . --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: gupnik <[email protected]>
-
- Jan 30, 2024
-
-
Oliver Tale-Yazdi authored
Add `Balances::force_adjust_total_issuance` as preparation for fixing https://github.com/polkadot-fellows/runtimes/issues/147 . Important changes in `substrate/frame/balances/src/lib.rs`. TODO: - [x] Update weights --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <[email protected]>
-
dharjeezy authored
closes https://github.com/polkadot-fellows/help-center/issues/1 --------- Signed-off-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Oliver Tale-Yazdi <[email protected]>
-
- Dec 20, 2023
-
-
joe petrowski authored
Adds the `authorize_upgrade` -> `enact_authorized_upgrade` pattern to `frame-system`. This will be useful for upgrading bridged chains that are under the governance of Polkadot without passing entire runtime Wasm blobs over a bridge. Notes: - Changed `enact_authorized_upgrade` to `apply_authorized_upgrade`. Personal opinion, "apply" more accurately expresses what it's doing. Can change back if outvoted. - Remove `check_version` in favor of two extrinsics, so as to make _checked_ the default. - Left calls in `parachain-system` and marked as deprecated to prevent breaking the API. They just call into the `frame-system` functions. - Updated `frame-system` benchmarks to v2 syntax. --------- Co-authored-by: command-bot <>
-
- Dec 18, 2023
-
-
Branislav Kontur authored
This PR contains just a few clippy fixes and nits, which are, however, relaxed by workspace clippy settings here: https://github.com/paritytech/polkadot-sdk/blob/master/Cargo.toml#L483-L506 --------- Co-authored-by: Dmitry Sinyavin <[email protected]> Co-authored-by: ordian <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <[email protected]>
-
- Dec 08, 2023
-
-
Muharem Ismailov authored
Treasury Pallet Instance for the Fellowship in Westend Collectives. In this update, we present a Treasury Pallet Instance that is under the control of the Fellowship body, with oversight from the Root and Treasurer origins. Here's how it is governed: - the Root origin have the authority to reject or approve spend proposals, with no amount limit for approvals. - the Treasurer origin have the authority to reject or approve spend proposals, with approval limits of up to 10,000,000 DOT. - Voice of all Fellows ranked at 3 or above can reject or approve spend proposals, with a maximum approval limit of 10,000 DOT. - Voice of Fellows ranked at 4 or above can also reject or approve spend proposals, with a maximum approval limit of 10,000,000 DOT. Additionally, we introduce the Asset Rate Pallet Instance to establish conversion rates from asset A to B. This is used to determine if a proposed spend amount involving a non-native asset is permissible by the commanding origin. The rates can be set up by the Root, Treasurer origins, or Voice of all Fellows. --------- Co-authored-by: joe petrowski <[email protected]> Co-authored-by: joepetrowski <[email protected]>
-
- Dec 06, 2023
-
-
Adrian Catangiu authored
# Motivation (+testing) ### Enable easy `ForeignAssets` transfers using `pallet-xcm` We had just previously added capabilities to teleport fees during reserve-based transfers, but what about reserve-transferring fees when needing to teleport some non-fee asset? This PR aligns everything under either explicit reserve-transfer, explicit teleport, or this new flexible `transfer_assets()` which can mix and match as needed with fewer artificial constraints imposed to the user. This will enable, for example, a (non-system) parachain to teleport their `ForeignAssets` assets to AssetHub while using DOT to pay fees. (the assets are teleported - as foreign assets should from their owner chain - while DOT used for fees can only be reserve-based transferred between said parachain and AssetHub). Added `xcm-emulator` tests for this scenario ^. # Description Reverts `(limited_)reserve_transfer_assets` to only allow reserve-based transfers for all `assets` including fees. Similarly `(limited_)teleport_assets` only allows teleports for all `assets` including fees. For complex combinations of asset transfers where assets and fees may have different reserves or different reserve/teleport trust configurations, users can use the newly added `transfer_assets()` extrinsic which is more flexible in allowing more complex scenarios. `assets` (excluding `fees`) must have same reserve location or otherwise be teleportable to `dest`. No limitations imposed on `fees`. - for local reserve: transfer assets to sovereign account of destination chain and forward a notification XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. - for destination reserve: burn local assets and forward a notification to `dest` chain to withdraw the reserve assets from this chain's sovereign account and deposit them to `beneficiary`. - for remote reserve: burn local assets, forward XCM to reserve chain to move reserves from this chain's SA to `dest` chain's SA, and forward another XCM to `dest` to mint and deposit reserve-based assets to `beneficiary`. - for teleports: burn local assets and forward XCM to `dest` chain to mint/teleport assets and deposit them to `beneficiary`. ## Review notes Only around 500 lines are prod code (see `pallet_xcm/src/lib.rs`), the rest of the PR is new tests and improving existing tests. --------- Co-authored-by: command-bot <>
-
- Nov 29, 2023
-
-
Liam Aharon authored
Westend SP dmp queue pallet removal is complete. <img width="1499" alt="Screenshot 2023-11-28 at 08 31 27" src="https://github.com/paritytech/polkadot-sdk/assets/16665596/906246fb-3de9-4133-a827-431636a097ad"> <img width="1499" alt="Screenshot 2023-11-28 at 08 32 08" src="https://github.com/paritytech/polkadot-sdk/assets/16665596/bde84891-b044-42c7-9a0b-59125cd24db1"> <img width="1499" alt="Screenshot 2023-11-28 at 08 31 45" src="https://github.com/paritytech/polkadot-sdk/assets/16665596/38337484-0856-45c0-b9ff-8c785bc3c0e3">
-
- Nov 15, 2023
-
-
Dónal Murray authored
Add collectives and glutton parachain westend runtimes to prepare for #1737. The removal of system parachain native runtimes #1737 is blocked until chainspecs and runtime APIs can be dealt with cleanly (merge of #1256 and follow up PRs). In the meantime, these additions are ready to be merged to `master`, so I have separated them out into this PR. Also marked `bridge-hub-westend` as unimplemented in line with [this issue](https://github.com/paritytech/parity-bridges-common/issues/2602 ). TODO - [x] add to `command-bot` benchmarks - [x] add to `command-bot-scripts` benchmarks - [x] generate weights --------- Co-authored-by: joe petrowski <[email protected]> Co-authored-by: Muharem <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Branislav Kontur <[email protected]>
-