... a few sessions too late :(, this already happened on polkadot, so as
of now there are no known relay-chains without async backing enabled in
runtime, but let's fix it in case someone else wants to repeat our
steps.
Fixes: https://github.com/paritytech/polkadot-sdk/issues/4226
---------
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Revert "pallet-xcm: Deprecate `execute` and `send` in favor of
`execute_blob` and `send_blob` (#3749)"
This reverts commit feee773d15.
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Javier Bullrich <javier@bullrich.dev>
It seems that `review-trigger` is not uploading the artifact that is
used by `review-bot`, so I changed the PR-Number to be obtained by the
previous event that triggered this action.
I also took the liberty to replace `tibdex/github-app-token` for
`actions/create-github-app-token` which is GitHub's official app.
Change `transfer_assets_using_type()` to not assume `DepositAssets` as
the intended use of the assets on the destination.
Instead provides the caller with the ability to specify custom XCM that
be executed on `dest` chain as the last step of the transfer, thus
allowing custom usecases for the transferred assets. E.g. some are
used/swapped/etc there, while some are sent further to yet another
chain.
Note: this is a follow-up on
https://github.com/paritytech/polkadot-sdk/pull/3695, bringing in an API
change for `transfer_assets_using_type()`. This is ok as the previous
version has not been yet released. Thus, its first release will include
the new API proposed by this PR.
This allows usecases such as:
https://forum.polkadot.network/t/managing-sas-on-multiple-reserve-chains-for-same-asset/7538/4
BTW: all this pallet-xcm asset transfers code will be massively reduced
once we have https://github.com/paritytech/xcm-format/pull/54
---------
Signed-off-by: Adrian Catangiu <adrian@parity.io>
Part of https://github.com/paritytech/polkadot-sdk/issues/4126 we want
to safely increase the execute_workers_max_num gradually from chain to
chain and assess if there are any negative impacts.
This PR performs the necessary plumbing to be able to increase it based
on the chain id, it increase the number of execution workers from 2 to 4
on test network but lives kusama and polkadot unchanged until we gather
more data.
---------
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
This PR updates the `validate_unsigned` hook for `frame_system` to allow
valid tasks to be submitted as unsigned transactions. It also updates
the task example to be able to submit such transactions via an off-chain
worker.
---------
Co-authored-by: Bastian Köcher <git@kchr.de>
This PR:
- adds `EnsureDecodableXcm` (testing) router that attempts to *encode*
and *decode* passed XCM `message` to ensure that the receiving side will
be able to decode, at least with the same XCM version.
- fixes `pallet_xcm` / `pallet_xcm_benchmarks` assets data generation
Relates to investigation of
https://substrate.stackexchange.com/questions/11288 and missing fix
https://github.com/paritytech/polkadot-sdk/pull/2129 which did not get
into the fellows 1.1.X release.
## Questions/TODOs
- [x] fix XCM benchmarks, which produces undecodable data - new router
catched at least two cases
- `BoundedVec exceeds its limit`
- `Fungible asset of zero amount is not allowed`
- [x] do we need to add `sort` to the `prepend_with` as we did for
reanchor [here](https://github.com/paritytech/polkadot-sdk/pull/2129)?
@serban300 (**created separate/follow-up PR**:
https://github.com/paritytech/polkadot-sdk/pull/4235)
- [x] We added decoding check to `XcmpQueue` -> `validate_xcm_nesting`,
why not to added to the `ParentAsUmp` or `ChildParachainRouter`?
@franciscoaguirre (**created separate/follow-up PR**:
https://github.com/paritytech/polkadot-sdk/pull/4236)
- [ ] `SendController::send_blob` replace `VersionedXcm::<()>::decode(`
with `VersionedXcm::<()>::decode_with_depth_limit(MAX_XCM_DECODE_DEPTH,
data)` ?
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
This should be configured on the runtime level and not somewhere inside
the pallet.
---------
Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Basically combines all the recommended calls into one
`build_using_defaults()` call or `init_with_defaults()` when there are
some custom changes required.
We cannot lock to a specific version of `psvm`, because we will need to
keep it up-to-date - each release currently requires a change in `psvm`
such as [this one](https://github.com/paritytech/psvm/pull/2/files).
There is no `stable` branch in `psvm` repo or anything so using the
default branch.
This is the first PR in preparation for
https://github.com/paritytech/polkadot-sdk/issues/454.
## Follow ups:
- https://github.com/paritytech/polkadot-sdk/pull/3904.
- https://github.com/paritytech/polkadot-sdk/pull/3905.
Overall changes are documented here (lot more visual 😍):
https://hackmd.io/@ak0n/454-np-governance
[Maybe followup](https://github.com/paritytech/polkadot-sdk/issues/4217)
with migration of storage item `VirtualStakers` as a bool or enum in
`Ledger`.
## Context
We want to achieve a way for a user (`Delegator`) to delegate their
funds to another account (`Agent`). Delegate implies the funds are
locked in delegator account itself. Agent can act on behalf of delegator
to stake directly on Staking pallet.
The delegation feature is added to Staking via another pallet
`delegated-staking` worked on
[here](https://github.com/paritytech/polkadot-sdk/pull/3904).
## Introduces:
### StakingUnchecked Trait
As the name implies, this trait allows unchecked (non-locked) mutation
of staking ledger. These apis are only meant to be used by other pallets
in the runtime and should not be exposed directly to user code path.
Also related: https://github.com/paritytech/polkadot-sdk/issues/3888.
### Virtual Bond
Allows other pallets to stake via staking pallet while managing the
locks on these accounts themselves. Introduces another storage
`VirtualStakers` that whitelist these accounts.
We also restrict virtual stakers to set reward account as themselves.
Since the account has no locks, we cannot support compounding of
rewards. Conservatively, we require them to set a separate account
different from the staker. Since these are code managed, it should be
easy for another pallet to redistribute reward and rebond them.
### Slashes
Since there is no actual lock maintained by staking-pallet for virtual
stakers, this pallet does not apply any slashes. It is then important
for pallets managing virtual stakers to listen to slashing events and
apply necessary slashes.
Some Rococo parachains lacked WS nodes. `ws/wss` endpoints are necessary
for using light clients on the testnet.
Changes:
1. Add `ws/wss` endpoints to all testnet parachains.
2. Remove decommissioned nodes (`people-collator-node-2`
`people-collator-node-3` ).
Related to https://github.com/paritytech/polkadot-sdk/issues/4126
discussion
Currently all preparations have same priority and this is not ideal in
all cases. This change should improve the finality time in the context
of on-demand parachains and when `ExecutorParams` are updated on-chain
and a rebuild of all artifacts is required. The desired effect is to
speed up approval and dispute PVF executions which require preparation
and delay backing executions which require preparation.
---------
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
This PR ensures that broadcast future cleans-up the submitted extrinsic
from the pool, iff the `broadcast_stop` operation has been called.
This effectively cleans-up transactions from the pool when the
`broadcast_stop` is called.
cc @paritytech/subxt-team
---------
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
The `next_retry_time` gets populated when a request receives an error
timeout or any other error, after thatn next_retry would check all
requests in the queue returns the smallest one, which then gets used to
move the main loop by creating a Delay
```
futures_timer::Delay::new(instant.saturating_duration_since(Instant::now())).await,
```
However when we retry a task for the first time we still keep it in the
queue an mark it as in flight so its next_retry_time would be the oldest
and it would be small than `now`, so the Delay will always triggers, so
that would make the main loop essentially busy wait untill we received a
response for the retry request.
Fix this by excluding the tasks that are already in-flight.
---------
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
This PR adds description to each of the sections of the Changelog part.
Changes are based on feedback that it wasn't that clear what exactly
`Node Dev`, `Runtime Dev` etc. means. Now, the description for each of
those parts is taken directly from the `prdoc` schema.
Closes https://github.com/paritytech/release-engineering/issues/197
PR adds `test-linux-stable-int` and `quick-benchmarks` as github action
jobs. It's a copy of `test-linux-stable-int` and `quick-benchmarks` from
gitlab ci and now it's needed to make a stress test for self-hosted
github runners. `test-linux-stable-int` and `quick-benchmarks` in gitlab
are still `Required` whereas this workflow is allowed to fail.
cc https://github.com/paritytech/infrastructure/issues/46
Alexandru Gheorghe