Related to https://github.com/paritytech/polkadot-sdk/pull/3905.
Since virtual stakers does not have a real balance, they should not be
allowed to be reaped.
The proper reaping for agents slashed will be done in a separate PR.
# ISSUE
- Link to issue: https://github.com/paritytech/polkadot-sdk/issues/4237
# DESCRIPTION
Remove all ModuleError with hard-coded indices to pallet Error. For
example:
```rs
Err(DispatchError::Module(ModuleError {
index: 4,
error: [2, 0, 0, 0],
message: Some("Filtered")
}))
```
To
```rs
let expected_result = Err(crate::Error::<Test>::Filtered.into());
assert_eq!(result, expected_result);
```
# TEST OUTCOME
```
test result: ok. 74 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s
```
---------
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Some traits are already included in the 2021 prelude and so shouldn't be
needed to use explicitly:
use `convert::TryFrom`, `convert::TryInto`, and `iter::FromIterator` are
removed.
( https://doc.rust-lang.org/core/prelude/rust_2021/ )
No breaking changes or change of functionality, so I think no PR doc is
needed in this case.
(Motivation: Removes some references to `sp-std`)
closes https://github.com/paritytech/polkadot-sdk/issues/426.
related to https://github.com/paritytech/polkadot-sdk/pull/1189.
Would help offchain programs to query if there are unclaimed pages of
rewards for a given era.
The logic could look like below
```js
// loop as long as all era pages are claimed.
while (api.call.stakingApi.pendingRewards(era, validator_stash)) {
api.tx.staking.payout_stakers(validator_stash, era)
}
```
Currently we discard errors content
We should at least log it.
Code now is more similar to what is written in try_on_runtime_upgrade.
label should be R0
---------
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Javier Bullrich <javier@bullrich.dev>
This PR includes two changes:
- added `workflow_dispatch` to review bot
- reverted #4271
### Added `workflow_dispatch` to review bot
This allows us, in the case that review-bot fails for some fork reasons,
to trigger it manually ensuring that we can overcame the problem with
the multiple actions while we look for a solution.
<img width="342" alt="image"
src="https://github.com/paritytech/polkadot-sdk/assets/8524599/f432f91b-829a-4da4-b4ca-54cc4fe280c8">
### Reverted #4271
Unfortunately, the changes added in #4271 do not work in forks.
Here is a lengthy discussion of many individuals facing the same problem
as me:
- [GitHub Action `pull_request` attribute empty in `workflow_run` event
object for PR from forked repo
#25220](https://github.com/orgs/community/discussions/25220)
So I had to revert it (but I updated the dependencies to latest).
#### Miscellaneous changes
I added a debug log at the end of review bot in case it fails so we can
easily debug it without having to make a lot of boilerplate and forks to
duplicate the environment.
TODOs:
- [x] wait and see if test `1` works;
- [x] ~think of whether we need remaining tests.~ I think we should keep
it - will try to revive and update it
There are some accounts that do not have a consumer ref while having a
reserve.
This adds a fail-safe mechanism to trigger in the case that
`does_consume` is true, but the assumption of `consumer>0` is not.
This should prevent those accounts from loosing balance and the TI from
getting messed up even more, but is not an "ideal" fix. TBH an ideal fix
is not possible, since on-chain data is in an invalid state.
---------
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Currently, PVFs are re-prepared if any execution environment parameter
changes. As we've recently seen on Kusama and Polkadot, that may lead to
a severe finality lag because every validator has to re-prepare every
PVF. That cannot be avoided altogether; however, we could cease
re-preparing PVFs when a change in the execution environment can't lead
to a change in the artifact itself. For example, it's clear that
changing the execution timeout cannot affect the artifact.
In this PR, I'm introducing a separate hash for the subset of execution
environment parameters that changes only if a preparation-related
parameter changes. It introduces some minor code duplication, but
without that, the scope of changes would be much bigger.
TODO:
- [x] Add a test to ensure the artifact is not re-prepared if
non-preparation-related parameter is changed
- [x] Add a test to ensure the artifact is re-prepared if a
preparation-related parameter is changed
- [x] Add comments, warnings, and, possibly, a test to ensure a new
parameter ever added to the executor environment parameters will be
evaluated by the author of changes with respect to its artifact
preparation impact and added to the new hash preimage if needed.
Closes#4132
... 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.
Ankan