Ep add release rc tagging gha #3
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds descriptions needed for publishing to crates.io.
…_v2 (paritytech#1561) I have added some Traits that are missing and are useful for dealing with non-fungible tokens on other pallets and their implementations for NFTs pallet. - In the Mutate trait, added methods for dealing with the metadata: `set_metadata`, `set_collection_metadata`, `clear_metadata` and `clear_collection_metadata`. The motivation of adding this methods coming from a StackExchange question asking for it: [Setting metadata of an item of the Nfts pallet in a custom pallet](https://substrate.stackexchange.com/questions/9974/setting-metadata-of-an-item-of-the-nfts-pallet-in-a-custom-pallet) - A Trait for trading non-fungible items. The methods in that Trait are `buy_item`, `set_price` and `item_price` An example of where this Trait can be useful is a pallet that deals with [NFT Royalties](https://forum.polkadot.network/t/nfts-royalty-pallet/3766) and needs to perform this actions. --------- Co-authored-by: Jegor Sidorenko <5252494+jsidorenko@users.noreply.github.com>
Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change in the logic of the action to overcome some problems with permissions coming from PRs from forks For this, we needed to divide the actions into two files: - A first action that triggers on PRs and reviews and uploads the PR number. - A second action which is triggered under the completion of the first one and runs as the action normally runs (but won't have any problems regarding permissions because it is triggered from the master branch)
Combination of paritytech/polkadot#7005, its addon PR paritytech/polkadot#7585 and its companion paritytech/cumulus#2433. This PR introduces a new XcmFeesToAccount struct which implements the `FeeManager` trait, and assigns this struct as the `FeeManager` in the XCM config for all runtimes. The struct simply deposits all fees handled by the XCM executor to a specified account. In all runtimes, the specified account is configured as the treasury account. XCM __delivery__ fees are now being introduced (unless the root origin is sending a message to a system parachain on behalf of the originating chain). # Note for reviewers Most file changes are tests that had to be modified to account for the new fees. Main changes are in: - cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery fees exponential factor - polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the FeeManager implementation - All runtime xcm_config files <- To add the FeeManager to the XCM configuration # Important note After this change, instructions that create and send a new XCM (Query*, Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport, DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock) will require the corresponding origin account in the origin register to pay for transport delivery fees, and the onward message will fail to be sent if the origin account does not have the required amount. This delivery fee is on top of what we already collect as tx fees in pallet-xcm and XCM BuyExecution fees! Wallet UIs that want to expose the new delivery fee can do so using the formula: ``` delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee) ``` where the delivery fee factor can be obtained from the corresponding pallet based on which transport you are using (UMP, HRMP or bridges), the base fee is a constant, the encoded message length from the message itself and the per byte fee is the same as the configured per byte fee for txs (i.e. `TransactionByteFee`). --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com> Co-authored-by: Giles Cope <gilescope@gmail.com> Co-authored-by: command-bot <> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
closes: paritytech/devops#2090 ## Changes 1. Updated the list of bootnodes. 2. Merged the Connect node and bootnode into a single node. 3. Decreased the number of nodes. 4. Updated the DNS name. ## Description The initial 8 bootnodes were planned to be replaced by community bootnodes, the community node was added but we did not bother to reduce the Parity managed bootnodes. Fixing it now.
`cargo install` takes a long time in CI. We want to run it relatively frequently without chewing through so much compute (see https://github.com/paritytech/ci_cd/issues/771) so I added automatic binary releases to the try-runtime-cli repo. A small added benefit is we can use it in our existing `on-runtime-upgrade` checks, which should cut their execution time by about half.
…ritytech#1911) When launching our [small network](https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/zombienet/examples/small_network.toml) for testing the node was crashing here shortly after launch: https://github.com/paritytech/polkadot-sdk/blob/5cdd819ed295645958afd9d937d989978fd0c84e/polkadot/node/collation-generation/src/lib.rs#L140 After changes in paritytech#1788 for the asset hub collator we are waiting for blocks of the shell runtime to pass before we initialize aura. However, this means that we attempted to initialize the collation related relay chain subsystems twice, leading to the error. I modified Aura to let it optionally take an already initialized stream of collation requests.
Changes: - Use a sensible limit for the overweight-cutoff of a single messages instead of the full configured `ServiceWeight`. - Add/Update tests --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Includes: - PoC for new `spot instance` infra for jobs. - Fixes in test-runner/cli
…1945) Just adding a prdoc for paritytech#1913 --------- Co-authored-by: Adrian Catangiu <adrian@parity.io>
) This PR prevents failures until paritytech#1946 is merged.
…tech#1920) The validators are checking if async backing is enabled by checking the version of the runtime api. If the runtime api is upgraded by a runtime upgrade, the validators start to also enable the async backing logic. However, just because async backing is enabled, it doesn't mean that all collators and parachain runtimes have upgraded. This pull request fixes an issue about advertising collations to the relay chain when it has async backing enabled, but the collator is still using the old networking protocol. The implementation is actually backwards compatible as we can not expect that everyone directly upgrades. However, the collation advertisement logic was requiring V2 networking messages after async backing was enabled, which was wrong. This is now fixed by this pull request. Closes: paritytech#1923 --------- Co-authored-by: eskimor <eskimor@users.noreply.github.com>
…aritytech#1942) Until now prometheus metrics were not exposed by the minimal relay chain node. Also slight cleanups.
Use a more secure seed for hashsets of cache.
Removed some debug logs
) The `xcm` crate was renamed to `staging-xcm` to be able to publish it to crates.io as someone as squatted `xcm`. The problem with this rename is that the `TypeInfo` includes the crate name which ultimately lands in the metadata. The metadata is consumed by downstream users like `polkadot-js` or people building on top of `polkadot-js`. These people are using the entire `path` to find the type in the type registry. Thus, their code would break as the type path would now be [`staging_xcm`, `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request fixes this by renaming the path segment `staging_xcm` to `xcm`. This requires: paritytech/scale-info#197 --------- Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
…ech#1812)" (paritytech#1950) This reverts paritytech#1812 until we know why it causes syncing issues reported in autonomys/subspace#2122.
This PR addresses several minor issues: - Fixes the symlink for `asset-hub-rococo.json` chainspec. - Corrects the `asset-hub-rococo-genesis` invulnerables setup. - Relocates common bash functions for bridge testing to a separate file `bridges_common.sh`.
in-progress PR adding new tests and solving bugs --------- Co-authored-by: Bradley Olson <34992650+BradleyOlson64@users.noreply.github.com> Co-authored-by: eskimor <eskimor@no-such-url.com> Co-authored-by: eskimor <eskimor@users.noreply.github.com> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
Bumps [aes-gcm](https://github.com/RustCrypto/AEADs) from 0.10.2 to 0.10.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/RustCrypto/AEADs/commit/7e82b01cd4901f6a35b5153536f11b87f5e4e622"><code>7e82b01</code></a> aes-gcm v0.10.3 (<a href="https://redirect.github.com/RustCrypto/AEADs/issues/552">#552</a>)</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/b587b27270cc300d39c496a1ab06be80d72ac107"><code>b587b27</code></a> aes-gcm: avoid exposing plaintext on tag verification failure (<a href="https://redirect.github.com/RustCrypto/AEADs/issues/551">#551</a>)</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/2209bcaa9edc65e9a60498e7ece5b50e66f32ebf"><code>2209bca</code></a> build(deps): bump actions/checkout from 3 to 4 (<a href="https://redirect.github.com/RustCrypto/AEADs/issues/548">#548</a>)</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/035ec25362886735a0f44098f85ba0501a9b4038"><code>035ec25</code></a> build(deps): bump ascon from 0.3.1 to 0.4.0 (<a href="https://redirect.github.com/RustCrypto/AEADs/issues/545">#545</a>)</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/e94ba5ab9fb2c7f3a18c92fb9dc8df14ac36f06b"><code>e94ba5a</code></a> xsalsa20poly1305: remove source code (<a href="https://redirect.github.com/RustCrypto/AEADs/issues/543">#543</a>)</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/31240c1285144aeabef3e80eb9a1b4137dc2b43f"><code>31240c1</code></a> Update Cargo.lock</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/40240c4a852df21048830de4eed4782c0fbddaef"><code>40240c4</code></a> Update Cargo.lock</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/be4ea6fd3bcc1c8a5a23974a43e0fc35104d8cba"><code>be4ea6f</code></a> Update Cargo.lock</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/2aef39e90d39c247cc89ccc31628468c9a9f60de"><code>2aef39e</code></a> Update Clippy version (<a href="https://redirect.github.com/RustCrypto/AEADs/issues/534">#534</a>)</li> <li><a href="https://github.com/RustCrypto/AEADs/commit/50710da0cbd47a4614b6d37119877f206c207e95"><code>50710da</code></a> Update Cargo.lock</li> <li>Additional commits viewable in <a href="https://github.com/RustCrypto/AEADs/compare/aes-gcm-v0.10.2...aes-gcm-v0.10.3">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/paritytech/polkadot-sdk/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Changes the maximum instances count for `wasmtime` to `64`. It also allows to only pass in maximum `32` for `--max-runtime-instances` as `256` was way too big. With `64` instances in total and `32` that can be configured in maximum, there should be enough space to accommodate for extra instances that are may required to be allocated adhoc. --------- Co-authored-by: Koute <koute@users.noreply.github.com>
✄ ----------------------------------------------------------------------------- Thank you for your Pull Request! 🙏 Please make sure it follows the contribution guidelines outlined in [this document](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md) and fill out the sections below. Once you're ready to submit your PR for review, please delete this section and leave only the text under the "Description" heading. # Description *Please include a summary of the changes and the related issue. Please also include relevant motivation and context, including:* - What does this PR do? make 'substrate-wasm-builder' manually set 'CARGO_TARGET_DIR' to '$project_dir/target' while building instead of unset 'CARGO_TARGET_DIR'; - Why are these changes needed? If you using this in the `build.rs` with following content in your `~/.cargo/config.toml': [build] target-dir = "target" the build process will stuck because of dead lock -- two `cargo build` on same target directory in the same time. There is already an attempt to avoid such dead lock by unset the `CARGO_TARGET_DIR`, but for users with config above in his build enviroment (like me), this workaround won't work. - How were these changes implemented and what do they affect? Instead of unset 'CARGO_TARGET_DIR', we set 'CARGO_TARGET_DIR' to '$project/target/', which is already assumed to be true by rest of the code. *Use [Github semantic linking](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) to address any open issues this PR relates to or closes.* Fixes # (issue number, *if applicable*) Closes # (issue number, *if applicable*) # Checklist - [x] My PR includes a detailed description as outlined in the "Description" section above - [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process) of this project (at minimum one label for `T` required) - [ ] I have made corresponding changes to the documentation (if applicable) - [ ] I have added tests that prove my fix is effective or that my feature works (if applicable) You can remove the "Checklist" section once all have been checked. Thank you for your contribution! ✄ ----------------------------------------------------------------------------- I have built my project with this fix, there's still some warnings with `build.target-dir` set but the building process won't hang. I haven't found related issue in this repo. But I did find one issue [here](https://github.com/substrate-developer-hub/substrate-node-template/issues/116).
The migration was missing to migrate `AvailabilityCores`. If this isn't migrated, all parachains in the availability phase would stall until the next session is started. This pull request fixes this by migrating this data. Besides that it is doing some cosmetics.
…tech#1979) ## Problem This PR addresses the issue with testnet AssetHub builds, which was discovered during the execution of `bot bench`. https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038738 ``` Compiling asset-hub-rococo-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-rococo-runtime) warning: Linking globals named 'Core_version': symbol multiply defined! error: failed to load bitcode of module "rococo_runtime-8799ee884447805a.rococo_runtime.0bc572b8-cgu.0.rcgu.o": warning: `asset-hub-rococo-runtime-wasm` (lib) generated 1 warning error: could not compile `asset-hub-rococo-runtime-wasm` (lib) due to previous error; 1 warning emitted ``` https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4038739 ``` Compiling asset-hub-westend-runtime-wasm v1.0.0 (/builds/parity/mirrors/polkadot-sdk/target/production/wbuild/asset-hub-westend-runtime) warning: Linking globals named 'Core_version': symbol multiply defined! error: failed to load bitcode of module "westend_runtime-86d7844430f97d5c.westend_runtime.b7678d03-cgu.0.rcgu.o": warning: `asset-hub-westend-runtime-wasm` (lib) generated 1 warning error: could not compile `asset-hub-westend-runtime-wasm` (lib) due to previous error; 1 warning emitted ``` ## Solution - Removed dependencies on `rococo-runtime` and `westend-runtime` introduced by [this PR](https://github.com/paritytech/polkadot-sdk/pull/1234/files#diff-a86375df98e04ca3cce1ea35c40257a222e2d5087f5f528ff33307678b78dc2dR534-R550). - Replaced `<rococo_runtime::Treasury as PalletInfoAccess>::index()` with `rococo_runtime_constants::TREASURY_PALLET_ID`. - Added `check_treasury_pallet_id` to the relay runtimes to ensure that the constant is aligned with the pallet id. - Added "Rococo Treasury" to the waived locations (that will not be charged fees in the executor) for `BridgeHubRococo` (to be aligned with AssetHubs). ## References [Full element discussion here](https://matrix.to/#/!JUeaZUiYbdrvzvtwSL:parity.io/$2PnjYMsWRjR7M3oOfGuRI0XkjdoqJLtRcAPVcDLuLVg?via=parity.io&via=web3.foundation). --------- Co-authored-by: command-bot <>
This PR does not introduce any functional changes to the existing code, it merely addresses several minor refactors: - Moving bridging pallets to separate files. - Improving the readability and naming of weight files for bridging pallets and bridging pallet instances. The reason for this refactor is to facilitate easier plugin integration for the upcoming bridge between Rococo and Westend. --------- Co-authored-by: command-bot <>
Reverts paritytech#1476 The `lock_pallet` / `unlock_pallet` additions in paritytech#1814 will result in less downtime for users than using runtime upgrades.
Even if the host configuration is returning `0` for the `lookahead`, we should schedule at least one job on a core if the core exists.
) Implements the `OnUnbalanced` trait to resolve received credits to the specified account. Credits that fail to resolve are dropped. ### Motivation Throughout the codebase, several types implement the trait with the same behavior. While some currently utilize older currency trait, a migration to the new fungible/s is anticipated for all. Examples: [1](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/cumulus/parachains/common/src/impls.rs#L37), [2](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/polkadot/runtime/common/src/impls.rs#L36), [3](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/substrate/bin/node/runtime/src/impls.rs#L40), [4](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/substrate/bin/node/runtime/src/lib.rs#L1969), [5](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/substrate/frame/broker/src/mock.rs#L198), [6](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/substrate/frame/society/src/lib.rs#L2031), [7](https://github.com/paritytech/polkadot-sdk/blob/1b34571c0c423115813034783ddf524aac257bf5/substrate/frame/treasury/src/lib.rs#L1118)
The `BlockBuilderProvider` was a trait that was defined in
`sc-block-builder`. The trait was implemented for `Client`. This
basically meant that you needed to import `sc-block-builder` any way to
have access to the block builder. So, this trait was not providing any
real value. This pull request is removing the said trait. Instead of the
trait it introduces a builder for creating a `BlockBuilder`. The builder
currently has the quite fabulous name `BlockBuilderBuilder` (I'm open to
any better name 😅). The rest of the pull request is about
replacing the old trait with the new builder.
# Downstream code changes
If you used `new_block` or `new_block_at` before you now need to switch
it over to the new `BlockBuilderBuilder` pattern:
```rust
// `new` requires a type that implements `CallApiAt`.
let mut block_builder = BlockBuilderBuilder::new(client)
// Then you need to specify the hash of the parent block the block will be build on top of
.on_parent_block(at)
// The block builder also needs the block number of the parent block.
// Here it is fetched from the given `client` using the `HeaderBackend`
// However, there also exists `with_parent_block_number` for directly passing the number
.fetch_parent_block_number(client)
.unwrap()
// Enable proof recording if required. This call is optional.
.enable_proof_recording()
// Pass the digests. This call is optional.
.with_inherent_digests(digests)
.build()
.expect("Creates new block builder");
```
---------
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>
Co-authored-by: command-bot <>
This PR is a follow up to paritytech#1661 - [x] rename the `simple` module to `legacy` - [x] fix benchmarks to disregard the number of additional fields - [x] change the storage deposits to charge per encoded byte of the identity information instance, removing the need for `fn additional(&self) -> usize` in `IdentityInformationProvider` - [x] ~add an extrinsic to rejig deposits to account for the change above~ - [ ] ~ensure through proper configuration that the new byte-based deposit is always lower than whatever is reserved now~ - [x] remove `IdentityFields` from the `set_fields` extrinsic signature, as per [this discussion](paritytech#1661 (comment)) > ensure through proper configuration that the new byte-based deposit is always lower than whatever is reserved now Not sure this is needed anymore. If the new deposits are higher than what is currently on chain and users don't have enough funds to reserve what is needed, the extrinisc fails and they're basically grandfathered and frozen until they add more funds and/or make a change to their identity. This behavior seems fine to me. Original idea [here](paritytech#1661 (comment)). > add an extrinsic to rejig deposits to account for the change above This was initially implemented but now removed from this PR in favor of the implementation detailed [here](paritytech#2088). --------- Signed-off-by: georgepisaltu <george.pisaltu@parity.io> Co-authored-by: joepetrowski <joe@parity.io>
This PR removes the `GenesisExt` wrapper over the `GenesisRuntimeConfig` in `cumulus-test-service`. Initialization of values that were performed by `GenesisExt::BuildStorage` was moved into `test_pallet` genesis. --------- Co-authored-by: command-bot <> Co-authored-by: Bastian Köcher <git@kchr.de>
closes paritytech#2020. This improves running time for pallet-bags-list try runtime checks on westend from ~90 minutes to 6 seconds on M2 pro.
Should help paritytech#234. Related to paritytech#2020 and paritytech#2108. Refactors and improves running time for try runtime checks for staking pallet. Tested on westend on my M2 pro: running time drops from 90 seconds to 7 seconds.
# Description Update the bootnode of kusama parachains before decommissioning the nodes. This will avoid connecting to non-existing bootnodes.
…#1256) This PR prepares chains specs for _native-runtime-free_ world. This PR has following changes: - `substrate`: - adds support for: - JSON based `GenesisConfig` to `ChainSpec` allowing interaction with runtime `GenesisBuilder` API. - interacting with arbitrary runtime wasm blob to[ `chain-spec-builder`](https://github.com/paritytech/substrate/blob/3ef576eaeb3f42610e85daecc464961cf1295570/bin/utils/chain-spec-builder/src/lib.rs#L46) command line util, - removes [`code`](https://github.com/paritytech/substrate/blob/3ef576eaeb3f42610e85daecc464961cf1295570/frame/system/src/lib.rs#L660) from `system_pallet` - adds `code` to the `ChainSpec` - deprecates [`ChainSpec::from_genesis`](https://github.com/paritytech/substrate/blob/3ef576eaeb3f42610e85daecc464961cf1295570/client/chain-spec/src/chain_spec.rs#L263), but also changes the signature of this method extending it with `code` argument. [`ChainSpec::builder()`](https://github.com/paritytech/substrate/blob/20bee680ed098be7239cf7a6b804cd4de267983e/client/chain-spec/src/chain_spec.rs#L507) should be used instead. - `polkadot`: - all references to `RuntimeGenesisConfig` in `node/service` are removed, - all `(kusama|polkadot|versi|rococo|wococo)_(staging|dev)_genesis_config` functions now return the JSON patch for default runtime `GenesisConfig`, - `ChainSpecBuilder` is used, `ChainSpec::from_genesis` is removed, - `cumulus`: - `ChainSpecBuilder` is used, `ChainSpec::from_genesis` is removed, - _JSON_ patch configuration used instead of `RuntimeGenesisConfig struct` in all chain specs. --------- Co-authored-by: command-bot <> Co-authored-by: Javier Viola <javier@parity.io> Co-authored-by: Davide Galassi <davxy@datawok.net> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Kevin Krone <kevin@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>
Related paritytech#2013 Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Otherwise the return code is not correctly propagated (ref ggwpez/zepter#48). --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Move peer banning from `ChainSync` to `SyncingEngine`.
This PR updates the version of `serde_json` to `1.0.108` throughout the codebase.
…itytech#2140) ... see paritytech#2138 for why is not good, until we fix it let's add a warning to understand if this is happening in the wild. --------- Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>
This PR exposes a `force_remove_vesting` through a ROOT call. See linked [issue](paritytech#269) --------- Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com> Co-authored-by: command-bot <> Co-authored-by: Dónal Murray <donal.murray@parity.io>
A quick fix where a benchmark test was wrongly renamed in this PR paritytech#1868
…certificate (paritytech#1178) **_PR migrated from https://github.com/paritytech/polkadot/pull/6782_** This PR will upgrade the network protocol to version 3 -> VStaging which will later be renamed to V3. This version introduces a new kind of assignment certificate that will be used for tranche0 assignments. Instead of issuing/importing one tranche0 assignment per candidate, there will be just one certificate per relay chain block per validator. However, we will not be sending out the new assignment certificates, yet. So everything should work exactly as before. Once the majority of the validators have been upgraded to the new protocol version we will enable the new certificates (starting at a specific relay chain block) with a new client update. There are still a few things that need to be done: - [x] Use bitfield instead of Vec<CandidateIndex>: paritytech/polkadot#6802 - [x] Fix existing approval-distribution and approval-voting tests - [x] Fix bitfield-distribution and statement-distribution tests - [x] Fix network bridge tests - [x] Implement todos in the code - [x] Add tests to cover new code - [x] Update metrics - [x] Remove the approval distribution aggression levels: TBD PR - [x] Parachains DB migration - [x] Test network protocol upgrade on Versi - [x] Versi Load test - [x] Add Zombienet test - [x] Documentation updates - [x] Fix for sending DistributeAssignment for each candidate claimed by a v2 assignment (warning: Importing locally an already known assignment) - [x] Fix AcceptedDuplicate - [x] Fix DB migration so that we can still keep old data. - [x] Final Versi burn in --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
…aritytech#2179) availability-distribution subsystem is not sending availability-recovery messages. Update the overseer declaration to reflect this
…1805) ### This PR is a port of this [PR for substrate](paritytech/substrate#13013) by @kianenigma Add infrastructure needed to have a Pallet::decode_entire_state(), which makes sure all "typed" storage items defined in the pallet are decode-able. This is not enforced in any way at the moment. Teams who wish to integrate/use this in the try-runtime feature flag should add frame_support::storage::migration::EnsureStateDecodes as the LAST ITEM of the runtime's custom migrations, and pass it to frame-executive. This will make it usable in try-runtime on-runtime-upgrade. This now catches cases like paritytech#1969: ```pre ERROR runtime::executive] failed to decode the value at key: Failed to decode value at key: 0x94eadf0156a8ad5156507773d0471e4ab8ebad86f546c7e0b135a4212aace339. Storage info StorageInfo { pallet_name: Ok("ParaScheduler"), storage_name: Ok("AvailabilityCores"), prefix: Err(Utf8Error { valid_up_to: 0, error_len: Some(1) }), max_values: Some(1), max_size: None }. Raw value: Some("0x0c010101010101") ``` ... or:  Closes paritytech#241 --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
…aritytech#1297) Original PR paritytech/substrate#14641 --- Closes paritytech#109 ### Problem Quoting from the above issue: > When adding a pallet to chain after genesis we currently don't set the StorageVersion. So, when calling on_chain_storage_version it returns 0 while the pallet is maybe already at storage version 9 when it was added to the chain. This could lead to issues when running migrations. ### Solution - Create a new trait `BeforeAllRuntimeMigrations` with a single method `fn before_all_runtime_migrations() -> Weight` trait with a noop default implementation - Modify `Executive` to call `BeforeAllRuntimeMigrations::before_all_runtime_migrations` for all pallets before running any other hooks - Implement `BeforeAllRuntimeMigrations` in the pallet proc macro to initialize the on-chain version to the current pallet version if the pallet has no storage set (indicating it has been recently added to the runtime and needs to have its version initialised). ### Other changes in this PR - Abstracted repeated boilerplate to access the `pallet_name` in the pallet expand proc macro. ### FAQ #### Why create a new hook instead of adding this logic to the pallet `pre_upgrade`? `Executive` currently runs `COnRuntimeUpgrade` (custom migrations) before `AllPalletsWithSystem` migrations. We need versions to be initialized before the `COnRuntimeUpgrade` migrations are run, because `COnRuntimeUpgrade` migrations may use the on-chain version for critical logic. e.g. `VersionedRuntimeUpgrade` uses it to decide whether or not to execute. We cannot reorder `COnRuntimeUpgrade` and `AllPalletsWithSystem` so `AllPalletsWithSystem` runs first, because `AllPalletsWithSystem` have some logic in their `post_upgrade` hooks to verify that the on-chain version and current pallet version match. A common use case of `COnRuntimeUpgrade` migrations is to perform a migration which will result in the versions matching, so if they were reordered these `post_upgrade` checks would fail. #### Why init the on-chain version for pallets without a current storage version? We must init the on-chain version for pallets even if they don't have a defined storage version so if there is a future version bump, the on-chain version is not automatically set to that new version without a proper migration. e.g. bad scenario: 1. A pallet with no 'current version' is added to the runtime 2. Later, the pallet is upgraded with the 'current version' getting set to 1 and a migration is added to Executive Migrations to migrate the storage from 0 to 1 a. Runtime upgrade occurs b. `before_all` hook initializes the on-chain version to 1 c. `on_runtime_upgrade` of the migration executes, and sees the on-chain version is already 1 therefore think storage is already migrated and does not execute the storage migration Now, on-chain version is 1 but storage is still at version 0. By always initializing the on-chain version when the pallet is added to the runtime we avoid that scenario. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de>
…ml (paritytech#2191) There was a race in merging between paritytech#1256 and paritytech#1178, so this newly added tests wasn't updated with the new path for the configuration, so fix that. Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
…h#2187) Part of paritytech#2186 The only usage of pallet-asset-rate is guarded by `runtime-benchmarks` feature. I don't want ORML to be forced to include this pallet in deps for no good reason.
# Description This merely fixes a typo in the documentation, replacing the typo "slashaed" with "slashed". Since external entities use the comments for explanations of events, this will then be shown externally. I noticed this when reviewing [this event](https://polkadot.subscan.io/extrinsic/0xb6bc1e3abde0c2ed9c500c74cfc64cdb8179e5d9af97f4bf53242ce4cdd15a1d?event=18064194-6) on Subscan. This is not related to any other issues or PRs.
…itytech#2202) When running with `--relay-chain-rpc-url` we received multiple reports of high traffic that disappears when `--in-peers-light 0` is set. Indeed it does not make much sense for light clients to connect to the minimal node since it is not running the block announce protocol and the request/response protocol for light clients. This is intended to alleviate the traffic issues for now. closes paritytech#1896 probably related paritytech/cumulus#2563
Added a proc macro to be able to write XCMs using the builder pattern.
This means we go from having to do this:
```rust
let message: Xcm<()> = Xcm(vec![
WithdrawAsset(assets),
BuyExecution { fees: asset, weight_limit: Unlimited },
DepositAsset { assets, beneficiary },
]);
```
to this:
```rust
let message: Xcm<()> = Xcm::builder()
.withdraw_asset(assets)
.buy_execution(asset, Unlimited),
.deposit_asset(assets, beneficiary)
.build();
```
---------
Co-authored-by: Keith Yeung <kungfukeith11@gmail.com>
Co-authored-by: command-bot <>
EgorPopelyaev
pushed a commit
that referenced
this pull request
Feb 20, 2024
1. Benchmark results are collected in a single struct. 2. The output of the results is prettified. 3. The result struct used to save the output as a yaml and store it in artifacts in a CI job. ``` $ cargo run -p polkadot-subsystem-bench --release -- test-sequence --path polkadot/node/subsystem-bench/examples/availability_read.yaml | tee output.txt $ cat output.txt polkadot/node/subsystem-bench/examples/availability_read.yaml #1 Network usage, KiB total per block Received from peers 510796.000 170265.333 Sent to peers 221.000 73.667 CPU usage, s total per block availability-recovery 38.671 12.890 Test environment 0.255 0.085 polkadot/node/subsystem-bench/examples/availability_read.yaml #2 Network usage, KiB total per block Received from peers 413633.000 137877.667 Sent to peers 353.000 117.667 CPU usage, s total per block availability-recovery 52.630 17.543 Test environment 0.271 0.090 polkadot/node/subsystem-bench/examples/availability_read.yaml #3 Network usage, KiB total per block Received from peers 424379.000 141459.667 Sent to peers 703.000 234.333 CPU usage, s total per block availability-recovery 51.128 17.043 Test environment 0.502 0.167 ``` ``` $ cargo run -p polkadot-subsystem-bench --release -- --ci test-sequence --path polkadot/node/subsystem-bench/examples/availability_read.yaml | tee output.txt $ cat output.txt - benchmark_name: 'polkadot/node/subsystem-bench/examples/availability_read.yaml #1' network: - resource: Received from peers total: 509011.0 per_block: 169670.33333333334 - resource: Sent to peers total: 220.0 per_block: 73.33333333333333 cpu: - resource: availability-recovery total: 31.845848445 per_block: 10.615282815 - resource: Test environment total: 0.23582828799999941 per_block: 0.07860942933333313 - benchmark_name: 'polkadot/node/subsystem-bench/examples/availability_read.yaml #2' network: - resource: Received from peers total: 411738.0 per_block: 137246.0 - resource: Sent to peers total: 351.0 per_block: 117.0 cpu: - resource: availability-recovery total: 18.93596025099999 per_block: 6.31198675033333 - resource: Test environment total: 0.2541994199999979 per_block: 0.0847331399999993 - benchmark_name: 'polkadot/node/subsystem-bench/examples/availability_read.yaml #3' network: - resource: Received from peers total: 424548.0 per_block: 141516.0 - resource: Sent to peers total: 703.0 per_block: 234.33333333333334 cpu: - resource: availability-recovery total: 16.54178526900001 per_block: 5.513928423000003 - resource: Test environment total: 0.43960946299999537 per_block: 0.14653648766666513 ``` --------- Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
EgorPopelyaev
pushed a commit
that referenced
this pull request
Apr 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.