Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Impl WeightTrader for tuple #3601

Merged
5 commits merged into from
Aug 18, 2021
Merged

Conversation

shaunxw
Copy link
Contributor

@shaunxw shaunxw commented Aug 9, 2021

This will allow to configure multiple traders for XCM execution fee.

@bkchr bkchr requested a review from shawntabrizi August 9, 2021 07:48
Comment on lines +95 to +99
for_tuples!( #(
if let Some(asset) = Tuple.refund_weight(weight) {
return Some(asset);
}
)* );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this make sense?

We could buy weight with one asset and return weight with another?

Copy link
Contributor Author

@shaunxw shaunxw Aug 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my understanding, a sensible WeightTrader impl would be that if weights are not bought here, then it won't refund. This is the case for all current traders like FixedRateOfFungible and UsingComponents. The tuple impl based on them would refund the same asset with which weights were bought.

This is covered in the added unit tests weight_trader_tuple_should_work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that makes sense

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to be the case if we assume that weight can only be bought by the native token of a chain. I'm trying to understand if this is still valid for assets that are non-native, e.g. USDC on Statemint/Statemine.

Would it be possible to buy weights using non-native tokens? If so, then a WeightTrader tuple may have elements that both accept the non-native token, and when refund_weight is called, the first WeightTrader in the tuple would refund first, which may not be the correct behaviour.

Copy link
Contributor Author

@shaunxw shaunxw Aug 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If so, then a WeightTrader tuple may have elements that both accept the non-native token, and when refund_weight is called, the first WeightTrader in the tuple would refund first, which may not be the correct behaviour.

The tuple impl tries buy/refund weights in the same order. If I understand your example correctly, in this case, the first trader buys weight, so it's fine that it refunds.

For instance, we have a tuple with two non-native token traders (UsdcTrader, UsdtTrader), if the assets are:

  1. Sufficient USDC. UsdcTrader do the buying and refund. UsdtTrader won't have the chance to try.
  2. Sufficient USDT. UsdtTrader buys and refunds. UsdcTrader tried both first but failed.
  3. Insufficient USDC/USDT. Both trader failed.

Copy link
Contributor

@KiChjang KiChjang Aug 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to carry an assumption that each token has a corresponding WeightTrader associated with it, e.g. USDC has a UsdcTrader and USDT has a UsdtTrader. Is this relationship guaranteed to always be 1:1? If so, then this logic looks to be sufficient enough.

What I'm more concerned about is when you have multiple WeightTraders that references the same token to trade. I'm imagining that some DeFi protocols may be permissive enough to allow for multiple tokens to be used to pay for fees, and each WeightTrader in their use case corresponds to a liquidity pool. Let's say both traders reference USDC as a token that they accept for paying for the weights. You'll then have Lp1Trader and Lp2Trader in a tuple, and the default behaviour here would then be to always buy and refund with Lp1Trader first, before Lp2Trader gets queried, which may result in an incorrect behaviour.

Though practically speaking, such a use case is complex enough to justify for a custom implementation of the WeightTrader trait on a self-defined type, and I wouldn't expect the developers of such a DeFi protocol to simply use a tuple to wrap the 2 WeightTraders. However, if that's the case, then I think it would be good to document what the default behaviour is when multiple WeightTraders are put inside of a tuple.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tuple impl doesn't assume 1:1 between tokens and traders. It's similar to SendXcm tuple that making no assumption of who sends what kind of messages, but simply try one by one until the msg is successfully sent. I think it's reasonable to make only one of the traders buy/refund weights, as the required weights shouldn't be bought/refunded twice, just like an XCM message should be sent twice. And yeah it's helpful to document this behavior.

I agree that for more complex requirements, ppl should really impl a trader themselves instead of expecting this tuple impl to help. Actually we're planning to impl a DEX trader in Karura, like in your example, and it will be used with other backup traders together.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KiChjang Thanks for helping to add documentations. 👍

@shawntabrizi shawntabrizi added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D5-nicetohaveaudit ⚠️ PR contains trivial changes to logic that should be properly reviewed. labels Aug 9, 2021
Comment on lines 86 to 89
for_tuples!( #(
if let Ok(assets) = Tuple.buy_weight(weight, payment.clone()) {
return Ok(assets);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This swallows any errors that might happen along the way. Not sure we want to do that.

Copy link
Member

@shawntabrizi shawntabrizi Aug 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the only thing we care about is if all of them fail, which is the final error below. Otherwise, we simply want to check with each trader if it is possible to buy weight, and if not, try the next one.

What do you think might be a better alternative here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that retry behavior is generally fine, but I think it would be good to at least surface the last error (returned by the last impl of buy_weight).
We should also add some logging (similar to the other XCM tracing I added) and maybe that can be enough.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just want to make sure it's possible to debug this at all (which I fear the current version is not).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is a trace log enough?

Copy link
Contributor

@apopiak apopiak Aug 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of:

	fn buy_weight(&mut self, weight: Weight, payment: Assets) -> Result<Assets, Error> {
		let mut last_error = None;
		for_tuples!( #(
			match Tuple.buy_weight(weight, payment.clone()) {
				Ok(assets) => return Ok(assets),
				Err(e) => { last_error = Some(e) }
			}
		)* );
		let last_error = last_error.unwrap_or(Error::TooExpensive);
		log::trace!(target: "xcm::buy_weight", "last_error: {:?}", last_error);
		Err(last_error)
	}

Copy link
Contributor Author

@shaunxw shaunxw Aug 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's helpful to add a trace log for debugging. Not sure about returning the last error, as it doesn't represent the reason why all traders failed. Probably using a more general error indicating buying weight failed is enough for callers IMHO.

@shaunxw
Copy link
Contributor Author

shaunxw commented Aug 16, 2021

Is this PR good to go, or we have to wait for more reviews?

@shawntabrizi
Copy link
Member

@shaunxw needs a second approve

Copy link
Contributor

@apopiak apopiak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see some way to get information about the inner errors if this fails so it is more debuggable.

@KiChjang
Copy link
Contributor

bot merge

@ghost
Copy link

ghost commented Aug 18, 2021

Trying merge.

@ghost ghost merged commit f3f83e3 into paritytech:master Aug 18, 2021
@shaunxw shaunxw deleted the sw/weight-trader-tuple branch August 18, 2021 02:07
@xlc xlc mentioned this pull request Sep 1, 2021
@chevdor chevdor added this to the v0.9.10 milestone Sep 2, 2021
chevdor pushed a commit that referenced this pull request Sep 2, 2021
* Impl WeightTrader for tuple.

* fmt

* Renaming.

* add tracing for buy_weight

* Add comment clarifying the default behavior of a WeightTrader tuple

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>
chevdor pushed a commit that referenced this pull request Sep 10, 2021
* Impl WeightTrader for tuple.

* fmt

* Renaming.

* add tracing for buy_weight

* Add comment clarifying the default behavior of a WeightTrader tuple

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>
chevdor pushed a commit that referenced this pull request Sep 13, 2021
* Impl WeightTrader for tuple.

* fmt

* Renaming.

* add tracing for buy_weight

* Add comment clarifying the default behavior of a WeightTrader tuple

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>
s3krit pushed a commit that referenced this pull request Sep 15, 2021
* Companion for substrate/pull/9442 (#3594)

* Fix compact build

* Fix again

* fix staking miner

* fmt

* update Substrate

Co-authored-by: parity-processbot <>

* More standard staking miner deposits (#3621)

* XCM v1 (#2815)

* MultiAsset TWO

* Draft next MultiAsset API.

* XCM core builds

* XCM Executor builds

* XCM Builder builds

* API changes making their way throughout

* Some TODOs

* Further build fixes

* Basic compile builds

* First test fixed

* All executor tests fixed

* Typo

* Optimize subsume_assets and add test

* Optimize checked_sub

* XCM Builder first test fixed

* Fix builder tests

* Fix doc test

* fix some doc tests

* spelling

* named fields for AllOf

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Reformat

* Move to XCM version 1

* Spelling

* warnings

* Replace some more v0->v1s

* warnings

* format

* Add max_assets param

* building

* test fixes

* tests

* another test

* final test

* tests

* Rename Null -> Here

* Introduce

* More ergonomics

* More ergonomics

* test fix

* test fixes

* docs

* BuyExecution includes

* Fix XCM extrinsics

* fmt

* Make Vec<MultiAsset>/MultiAssets conversions safe

* More MultiAssets conversion safety

* spelling

* fix doc test

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* fmt

* Add v0, remove VersionedMultiAsset

* Remove VersionedMultiLocation

* Update xcm/src/v1/order.rs

Co-authored-by: Amar Singh <[email protected]>

* Update xcm/src/v1/mod.rs

Co-authored-by: Amar Singh <[email protected]>

* XCM v0 backwards compatibility

* Full compatibility

* fmt

* Update xcm/pallet-xcm/src/lib.rs

* Update xcm/src/v0/order.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Tweaks to versioning system

* Fixes

* fmt

* Update xcm/xcm-executor/src/assets.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Update xcm/xcm-executor/src/assets.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Grumbles

* Update xcm/src/v1/multiasset.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* fmt

* Update xcm/src/v1/multiasset.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Update xcm/src/v1/multiasset.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Fixes

* Formatting

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Amar Singh <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>

* XCM v1 (#2815)

* MultiAsset TWO

* Draft next MultiAsset API.

* XCM core builds

* XCM Executor builds

* XCM Builder builds

* API changes making their way throughout

* Some TODOs

* Further build fixes

* Basic compile builds

* First test fixed

* All executor tests fixed

* Typo

* Optimize subsume_assets and add test

* Optimize checked_sub

* XCM Builder first test fixed

* Fix builder tests

* Fix doc test

* fix some doc tests

* spelling

* named fields for AllOf

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Reformat

* Move to XCM version 1

* Spelling

* warnings

* Replace some more v0->v1s

* warnings

* format

* Add max_assets param

* building

* test fixes

* tests

* another test

* final test

* tests

* Rename Null -> Here

* Introduce

* More ergonomics

* More ergonomics

* test fix

* test fixes

* docs

* BuyExecution includes

* Fix XCM extrinsics

* fmt

* Make Vec<MultiAsset>/MultiAssets conversions safe

* More MultiAssets conversion safety

* spelling

* fix doc test

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* fmt

* Add v0, remove VersionedMultiAsset

* Remove VersionedMultiLocation

* Update xcm/src/v1/order.rs

Co-authored-by: Amar Singh <[email protected]>

* Update xcm/src/v1/mod.rs

Co-authored-by: Amar Singh <[email protected]>

* XCM v0 backwards compatibility

* Full compatibility

* fmt

* Update xcm/pallet-xcm/src/lib.rs

* Update xcm/src/v0/order.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Tweaks to versioning system

* Fixes

* fmt

* Update xcm/xcm-executor/src/assets.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Update xcm/xcm-executor/src/assets.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Grumbles

* Update xcm/src/v1/multiasset.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* fmt

* Update xcm/src/v1/multiasset.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Update xcm/src/v1/multiasset.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Fixes

* Formatting

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Amar Singh <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>

* Companion to #9514 (Remove Filter and use Contains instead) (#3591)

* Remove Filter and use Contains instead

* Fixes

* Remove patch

* Formatting

* update Substrate

Co-authored-by: parity-processbot <>

* Fix Backwards Compatability with v0 Response (#3597)

* fix junction + response

* Update xcm/src/v1/mod.rs

* better comment

* Minor fix to encoding for XCM v1 (#3602)

* Ensure MultiLocation always has a canonical representation (#3404)

* MultiAsset TWO

* Ensure MultiLocation always has a canonical representation

* Remove v1 module

* Draft next MultiAsset API.

* Implement custom encoding/decoding scheme for MultiLocation

* Properly implement IntoIterator for Junctions

* Implement TryFrom<MultiLocation> for Junctions

* Fix spelling mistakes

* Fix tests in xcm-executor

* XCM core builds

* XCM Executor builds

* XCM Builder builds

* Fix xcm-builder tests and compilation

* Make pallet-xcm compile

* Use MultiLocation::default()

* Make polkadot-runtime-common compile

* Make rococo-runtime compile

* Change return type of parent_count to u8

* Change MAX_MULTILOCATION_LENGTH to 255

* Make kusama-runtime compile

* Fix logic in pallet-xcm

* Use MultiLocation::empty()

* Fix logic in location_conversion

* Fix logic in origin_conversion.rs

* Make westend-runtime compile

* Rename prefixes and suffixes variables

* Rename non_parent to interior

* Rename non_parent to interior

* Add test for encode/decode roundtrip and fix decode algorithm

* API changes making their way throughout

* Some TODOs

* Further build fixes

* Rename non_parent/junctions to interior

* Basic compile builds

* First test fixed

* All executor tests fixed

* Typo

* Optimize subsume_assets and add test

* Optimize checked_sub

* XCM Builder first test fixed

* Fix builder tests

* Fix doc test

* Make xcm-simulator compile

* Make xcm-simulator-example compile

* Make spellcheck happy

* cargo fmt

* fix some doc tests

* spelling

* named fields for AllOf

* Fix subtle bug where Null is treated as an identifier

* Add FIXME comment awaiting for const generics eval stabilization

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Update xcm/src/v0/multiasset.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Reformat

* Move to XCM version 1

* Spelling

* warnings

* Replace some more v0->v1s

* warnings

* format

* Add max_assets param

* building

* test fixes

* tests

* another test

* final test

* Update rustdocs and add debug_assert where sensible

* Revert debug_assert in const fn len()

* tests

* Rename Null -> Here

* Introduce

* More ergonomics

* More ergonomics

* test fix

* test fixes

* docs

* BuyExecution includes

* Fix XCM extrinsics

* fmt

* Make Vec<MultiAsset>/MultiAssets conversions safe

* More MultiAssets conversion safety

* spelling

* fix doc test

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* fmt

* Add v0, remove VersionedMultiAsset

* Remove VersionedMultiLocation

* Update xcm/src/v1/order.rs

Co-authored-by: Amar Singh <[email protected]>

* Update xcm/src/v1/mod.rs

Co-authored-by: Amar Singh <[email protected]>

* XCM v0 backwards compatibility

* Full compatibility

* fmt

* Update xcm/pallet-xcm/src/lib.rs

* Update xcm/src/v0/order.rs

Co-authored-by: Shawn Tabrizi <[email protected]>

* Tweaks to versioning system

* Fixes

* fmt

* Fix pallet-xcm tests

* fix

* Substitute with_parent with with_parents_const

* Rename argument name from a to m

* Rename split_last to split_last_interior

* Allow adding multiple parents in MultiLocation

* Rename pop_parent to dec_parent

* Ensure relay chain XCM sender receives a MultiLocation without any parents

* Block only when MultiLocation destination length is 8

* Cargo fmt

* Remove reverse iterators, implement DoubleEndedIterator and add tests

* Fix iter_rev lifetime requirements

* Cargo fmt

* Add an into() method for Junctions for conciseness in const context

* Ensure parent count is 0 while executing who in RelayedFrom

* Appease spellchecker

* Use and_then instead of repeated map_err

* Remove custom codec indices for v1 Junctions

* Add convenience 'contains_parents_only' method to MultiLocation

* Fix merge conflict

* Use more convenience methods

* Remove with_parachain_interior

* Prefer matching against tuple instead of using match guards

* Match against tuple instead of using more match guards

* Update encode/decode test for MultiLocation

* Minor tweaks

* Fixes

* Fixes

* Fixes

* Fix MultiLocation

* Add deprecation note for iter_rev and into_iter_rev

* Update some rustdocs

* cargo fmt

* Fix xcm-executor unit tests

* Fix compilation and unit tests in xcm-builder

* cargo fmt

* Fix tests in xcm-simulator-example

* Publicize MultiLocation fields

* Match on the MultiLocation struct directly in xcm-builder

* Do not dereference undereferenceable types

* Add convenience MultiLocation conversions for tuples

* Use clearer import paths

* Remove unused dependency

* fix junction + response

* Import from latest opaque xcm module

* Update xcm/src/v1/mod.rs

* better comment

* Fix ownership transfer

* Fix merge

* Fix merge

* cargo fmt

* Fix merge

* Fix merge

* Fix integration test

* More readable Parent syntax

* cleanup

* cleanup

* cleanup

* cleanup

* cleanup

* cleanup

* cleanup

* cleanup

* cargo fmt

* Fixes

* Fix doc test

Co-authored-by: Gav Wood <[email protected]>
Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Amar Singh <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>

* Make RelayedFrom typesafe (#3617)

* Corrent type

* Fix build

* Fixes

* Fixes

* Formatting

* Remove BuyExecution::orders (#3640)

* Remove BuyExecution::orders

* Fixes

* Fixes

* Fixes

* Formatting

* XCM: Introduce versioning to dispatchables' params (#3693)

* Introduce versioning to dispatchables' params

* Fixes

* Formatting

* Bump

* Bump deps

* Fixes

* Fixes

* check runtime version in staking miner (#3628)

* check runtime version in staking miner

* fmt

* add short alias for things

* fix fee

* print length as well

* fix build

* review comments

* add integration tests to xcm-builder (#3537)

* add integration tests to xcm-builder

* add an integration test for reserve_transfer_assets

* add query holding and teleport tests

* formatting

* add to barrier doc comments and fix doc tests warnings

* use more realistic barrier for integration tests

* improve imports

* adjust base xcm weight and existential deposit to be in line with Kusama

* remove AnyNetwork

Co-authored-by: Amar Singh <[email protected]>

* add more comments and remove unnecessary code

* move mock into separate file

* reduce imports

* update cargo.lock

* remove reserve transfer test from xcm builder integration tests

* reword barrier doc comment

* elaborate on QueryHolding test scenario

* add an integration test for reserve based transfers from parachain to parachain

* add teleport tests

* fix failing teleport filter tests

* Update xcm/xcm-builder/src/integration_tests.rs

Co-authored-by: Kian Paimani <[email protected]>

* Update xcm/xcm-builder/src/integration_tests.rs

Co-authored-by: Kian Paimani <[email protected]>

* Update xcm/xcm-builder/src/integration_tests.rs

Co-authored-by: Kian Paimani <[email protected]>

* Move integration tests to tests/ directory

* Fix merge

* Replace All wildcard with a concrete seed amount

* Rename SEED_AMOUNT to REGISTER_AMOUNT

* Fix compilation error

* Check for teleport destination first before checking out assets

* Fix unit test

* Do not run tests in integration mock

* Add a permissive assets filter for teleportation

* Remove check for teleport location in InitiateTeleport XCM

* Remove defunct test

* Apply suggestions from code review

Co-authored-by: Kian Paimani <[email protected]>

* Reword comment

Co-authored-by: Amar Singh <[email protected]>
Co-authored-by: Kian Paimani <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>

* Impl WeightTrader for tuple (#3601)

* Impl WeightTrader for tuple.

* fmt

* Renaming.

* add tracing for buy_weight

* Add comment clarifying the default behavior of a WeightTrader tuple

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>

* fix compilation (#3657)

* Use proc macros to generate conversion functions for MultiLocation (#3635)

* Use proc macros to generate conversion functions for MultiLocation

* Add compile test and missing conversion cases

* Add common derives for Parent and Ancestor

* Generate conversion functions for MultiLocation v0 via proc macro

* Add type conversion test and fix a bug

* cargo fmt

* Do not hardcode 8 as the number of max parents

* Use map instead of for loops when generating code fragments

* Spelling

* cargo fmt

* More mapping, less for-looping

* Improve MultiLocation conversion functions in xcm-procedural (#3690)

* Use fully-qualified paths to reference core traits in proc macro

* Ensure a canonicalized v0 MultiLocation first before attempting to convert to v1

* Fix failing test

* XCM v1 version notification stub (#3766)

* Initial draft

* v1 subscriptions

* Fixes

* Fixes

* Formatting

* Fixes

* Formatting

* chore: update substrate to branch polkadot-v0.9.10

* chore: update beefy to branch polkadot-v0.9.10

* Provide dummy dispute coordinator by default. (#3661)

* Provide dummy dispute coordinator by default.

* cargo fmt

* Fill up requests slots via `launch_parallel_requests` (#3681)

in case waiting for the next response takes too long.

* Fix missing overseer feature

* Update beefy deps

* xcm executor version bump

* Remove request multiplexer (#3624)

* WIP: Get rid of request multiplexer.

* WIP

* Receiver for handling of incoming requests.

* Get rid of useless `Fault` abstraction.

The things the type system let us do are not worth getting abstracted in
its own type. Instead error handling is going to be merely a pattern.

* Make most things compile again.

* Port availability distribution away from request multiplexer.

* Formatting.

* Port dispute distribution over.

* Fixup statement distribution.

* Handle request directly in collator protocol.

+ Only allow fatal errors at top level.

* Use direct request channel for availability recovery.

* Finally get rid of request multiplexer

Fixes #2842 and paves the way for more back pressure possibilities.

* Fix overseer and statement distribution tests.

* Fix collator protocol and network bridge tests.

* Fix tests in availability recovery.

* Fix availability distribution tests.

* Fix dispute distribution tests.

* Add missing dependency

* Typos.

* Review remarks.

* More remarks.

* Add words to the dictionnary

* sp-io update

* Don't drop UMP queue items if weight exhausted (#3784)

* Requeue UMP queue items if weight exhausted

* Reduce complexity and remove Deque

* Formatting

* Formatting

* Avoid needless storage writes

* Test

* Formatting

* Docs and cleanup

* fmt

* Remove now irrelevant comment.

* Simplify `take_processed` by using `mem::take`

* Clean up & fmt: use `upward_message` directly.

* Grumbles

Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: Sergei Shulepov <[email protected]>

* Update beefy deps

* Update Substrate and Beefy

* fix for #3537

* Update substrate

* Fix spelling

* Do not expire HRMP open channel requests (#3543)

* Do not expire HRMP open channel requests

* Fix the build and update the docs

* Implement canceling requests and do not remove them automatically

* Fix a borked merge

* Fix fmt

* Please spellchecker

* Apply suggestions from code review

Co-authored-by: Amar Singh <[email protected]>

* Use `mutate_exists` for maintaining request counts

* Apply `rustfmt`

* Move newly introduced entrypoint to end to preserve ordering

Co-authored-by: Amar Singh <[email protected]>

* UMP: Support Overweight messages (#3575)

* Introduce new config: ump_max_individual_weight

* Implement overweight msg stashing

* Test

* Add migration module.

Also introduces a test for migration

* Integrate ExecuteOverweightOrigin to runtimes

* Fix more stuff

* Add `yeet` into dictionary

* Use suggested `Error` variant names

* typo

* Use 20ms as the maximum individual message weight

* Update the test value

* rustfmt

* Clean up

* Remove deprecated field from host config

* Remove missed _hrmp_open_request_ttl

* Apply typo fix suggestion

Co-authored-by: Alexander Popiak <[email protected]>

* Rename `migration::migrate_to_latest`

* Restore `_hrmp_open_request_ttl` in `v0::HostConfiguration`

* Apply suggestion for a rustdoc

* Apply the suggestion

* Test v0 config with the raw production data fetched from Kusama

* Update runtime/parachains/src/ump.rs

Co-authored-by: Alexander Popiak <[email protected]>

* Expose migration functions

* Fix spellcheck

Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>

* Remove migration done by runtime version 9090 (#3731)

* remove 9090 migrations

* remove unused

* fmt

* revert removal of polkadot migration

* remove migration for polkadot

Co-authored-by: Kian Paimani <[email protected]>
Co-authored-by: Gavin Wood <[email protected]>
Co-authored-by: Alexander Popiak <[email protected]>
Co-authored-by: Amar Singh <[email protected]>
Co-authored-by: Shawn Tabrizi <[email protected]>
Co-authored-by: Keith Yeung <[email protected]>
Co-authored-by: Shaun Wang <[email protected]>
Co-authored-by: Guillaume Thiolliere <[email protected]>
Co-authored-by: Robert Klotzner <[email protected]>
Co-authored-by: Sergei Shulepov <[email protected]>
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D5-nicetohaveaudit ⚠️ PR contains trivial changes to logic that should be properly reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants