-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IT: Simplify liquidity_pool test module #1869
Conversation
8ccf242
to
650e96e
Compare
650e96e
to
0bc96f6
Compare
|
||
assert_eq!( | ||
orml_tokens::Pallet::<T>::free_balance(curr.id(), &Keyring::Alice.id()), | ||
curr.val(INITIAL) - curr.val(TRANSFER) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: the val()
method will create the balance with the correct decimals based on the currency it is. We no longer need usd6()
/usd12()
/usd18()
methods which leads to errors mixing different amounts.
|
||
assert_ne!(1000u128, 996.approx(0.01)); | ||
assert_ne!(1000u128, 1004.approx(-0.01)); | ||
assert_ne!(1000u128, 1500.approx(0.1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The value 0.01
means that both values are equal if the right-hand side is as much as 1% higher than the other one. -0.01
means lower than.
02ca1ad
to
5b41f5e
Compare
There are a lot of git diffs in |
assert_eq!( | ||
CurrencyIdConvert::<T>::convert(Location::new(0, Here)), | ||
Some(curr.id()), | ||
); | ||
|
||
assert_eq!(CurrencyIdConvert::<T>::convert(curr.id()), None); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, here I would expect a symmetric behavior, but it isn't.
The implementation only checks the transferability when converting from location -> currency
ref. Should we add the same filter for currency -> location
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly not sure if we want this to be symmetric. AFAICT, we could switch to that based on my below observations.
If we decide on that, it blocks converting any local currency locations into their corresponding currency id. One implication is that those currencies cannot be used for paying XCM transaction fees. On mainnet, CFG is configured as XCM transferable.
It would be interesting to see the failing tests when switching to symmetric behaviour. Depending on the failing tests, this could be a good indicator on whether we require location-to-currency location for local currencies as part of XCM for instance.
AFAICS, the CurrencyIdConvert
is used to determine and withdraw cross-chain fee amounts in the configured fee currency in three different pallets:
- As
orml_xtokens::CurrencyIdConvert
to derive the asset origination location - As
pallet_xcm_transactor::CurrencyIdLocation
to withdraw the fee amount of the configured fee currency - In
staging_xcm_executor::Config::AssetTransactor = FungiblesTransactor
asMatcher
AT of ourFungiblesAdaptor
impl to withdraw the XCM fee in the configured fee currencies
Curious about your thoughts @mustermeiszer
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1869 +/- ##
==========================================
- Coverage 46.87% 46.84% -0.03%
==========================================
Files 170 170
Lines 13223 13221 -2
==========================================
- Hits 6198 6194 -4
- Misses 7025 7027 +2 ☔ View full report in Codecov by Sentry. |
f285d2e
to
5a832ad
Compare
/// Fees will be charged using `FixedRateOfFungible`. | ||
#[cfg(feature = "std")] | ||
pub fn xcm_default() -> Self { | ||
Self::Xcm(XcmMetadata { | ||
fee_per_second: None, | ||
}) | ||
} | ||
|
||
/// Fees will be charged using `AssetRegistryTrader`. | ||
/// If value is 0, no fees will be charged. | ||
#[cfg(feature = "std")] | ||
pub fn xcm_with_fees(value: Balance) -> Self { | ||
Self::Xcm(XcmMetadata { | ||
fee_per_second: Some(value), | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tech-debt to create some tests to be able to compute the exact fee charged in the above two cases. Using FixedRateOfFungible
and using AssetRegistryTrader
ec2c1e5
to
de3760a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super organized and clean, love it! Two minor nits, which can be ignored and one comment from my side.
assert_eq!( | ||
CurrencyIdConvert::<T>::convert(Location::new(0, Here)), | ||
Some(curr.id()), | ||
); | ||
|
||
assert_eq!(CurrencyIdConvert::<T>::convert(curr.id()), None); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly not sure if we want this to be symmetric. AFAICT, we could switch to that based on my below observations.
If we decide on that, it blocks converting any local currency locations into their corresponding currency id. One implication is that those currencies cannot be used for paying XCM transaction fees. On mainnet, CFG is configured as XCM transferable.
It would be interesting to see the failing tests when switching to symmetric behaviour. Depending on the failing tests, this could be a good indicator on whether we require location-to-currency location for local currencies as part of XCM for instance.
AFAICS, the CurrencyIdConvert
is used to determine and withdraw cross-chain fee amounts in the configured fee currency in three different pallets:
- As
orml_xtokens::CurrencyIdConvert
to derive the asset origination location - As
pallet_xcm_transactor::CurrencyIdLocation
to withdraw the fee amount of the configured fee currency - In
staging_xcm_executor::Config::AssetTransactor = FungiblesTransactor
asMatcher
AT of ourFungiblesAdaptor
impl to withdraw the XCM fee in the configured fee currencies
Curious about your thoughts @mustermeiszer
Description
There are a lot of overlapping and boilerplate in the current liquidity-pool tests.
approx()
to check approximation amounts.liquidity_pools.rs
into their own files, trying to avoid as much testing overlapping as possible:transfer
intoxcm_transfer.rs
file:asset_registry
intoassets.rs
file.currency_id_convert
intocurrency_conversion.rs
file.restricted_tokens
into the already existentrestricted_tokens.rs
file.PARA_ID
andSIBLING_ID
no longer tied toFudgeHandle
. They are gloval values that can be read in any place without usingT::FudgeHandle
I do not touch any tests related to liquidity pools itself. I want to give them support for altair and centrifuge and remove the Fudge requirement in another PR. Also, I think there is a lot of overlap with the new
lp
module, so maybe some of them can just be removed.Next in line (future PRs):