-
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
Fix: LP accounting #1657
Fix: LP accounting #1657
Conversation
The migration itself works, but I still get a panic. @wischli do you have a clue what could be the issue here:
|
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.
Two minor nits and one logical error in the post checks. Unfortunately, some integration tests will very likely fail which requires minor fixing.
); | ||
} | ||
|
||
T::DbWeight::get().reads(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.
The weight is off. Unfortunately, we don't have weights for burn_from
. Looking at the source code, 2 reads + 2 writes from mutating the account and the total issuance seem feasible.
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.
Blocker: Weight is still off
T::DbWeight::get().reads(1) | |
T::DbWeight::get().reads_writes(2, 2) |
runtime/centrifuge/src/migrations.rs
Outdated
if !post_data.free.is_zero() | ||
&& !post_data.frozen.is_zero() | ||
&& !post_data.reserved.is_zero() |
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.
Wrong logical concatenation: Should be !(free == 0 && frozen == 0 && reserve == 0)
or respectively!free == 0 || !frozen == 0 || !reserved == 0
.
runtime/centrifuge/src/migrations.rs
Outdated
); | ||
|
||
if !pre_data.frozen.is_zero() && !pre_data.reserved.is_zero() { | ||
log::error!("AccountData of Ethereum domain account has non free balances..."); |
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.
Nit: Since this is only executed in try-runtime
, it would be feasible to panic here.
runtime/centrifuge/src/migrations.rs
Outdated
T: orml_tokens::Config + frame_system::Config, | ||
<T as orml_tokens::Config>::CurrencyId: From<CurrencyId>, |
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.
NIT: Could be the above be
T: orml_tokens::Config + frame_system::Config, | |
<T as orml_tokens::Config>::CurrencyId: From<CurrencyId>, | |
T: orml_tokens::Config<CurrencyId = CurrencyId> + frame_system::Config, |
to avoid into()
s?
runtime/centrifuge/src/migrations.rs
Outdated
T::CurrencyId::from(LP_ETH_USDC), | ||
); | ||
|
||
if !pre_data.frozen.is_zero() && !pre_data.reserved.is_zero() { |
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.
I am not sure if I'm right, don't you want instead
if !pre_data.frozen.is_zero() && !pre_data.reserved.is_zero() { | |
if !pre_data.frozen.is_zero() || !pre_data.reserved.is_zero() { |
?
runtime/centrifuge/src/migrations.rs
Outdated
if !post_data.free.is_zero() | ||
&& !post_data.frozen.is_zero() | ||
&& !post_data.reserved.is_zero() |
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.
Same here, with ||
?
<Domain as Convert<_, T::AccountId>>::convert(ETH_DOMAIN), | ||
T::CurrencyId::from(LP_ETH_USDC), | ||
); | ||
|
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.
Should we check here also frozen
and reserved
?
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.
To be safe, we should not burn if either of these entries are non-zero, IMO.
); | ||
} | ||
|
||
T::DbWeight::get().reads(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.
And 1 writing, I think
Practically overwriting the @william suggestions 😆 |
As discussed synchronously, the panic is unrelated to this migration as I also experienced it with an empty migration tuple when testing the 1024 upgrade. I suppose these panics were suppressed (only logged) before our update to v0.9.43. |
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.
Second round! Some questions, but I think everything is tied 👍🏻
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 migration weight was not updated. Apart from that LGTM!
/// The asset is transferable through all available options | ||
All(XcmMetadata), |
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.
Q: Curious about this change. Another feature creep?
); | ||
} | ||
|
||
T::DbWeight::get().reads(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.
Blocker: Weight is still off
T::DbWeight::get().reads(1) | |
T::DbWeight::get().reads_writes(2, 2) |
I will leave that for now. Runtime upgrades block the whole block anyways, and we probably only going to have loans migration besides this one. |
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.
Approving due to expected underweight of migrations for 1025
Description
Currently, when tokens are transfered to another domain we are storing them in the domain specific account. That is correct for tranche tokens, as Centrifuge Chain is the reserve for these kind of tokens. But all other tokens that are LP transferable are tokens where the domain is the reserve, hence we need to burn them instead.
This PR fixes the code to burn instead and furthermore provides a migration for Centrifuge Chain to burn existing tokens.
NOTE: We must burn all LP tokens from this account, as we are now also deployed on
Celo
,Arbitrum
andBase
we must be cautious whether we need to extend the burn-migration toUSDC
from these domains.Changes and Descriptions
burn_from
instead oftransfer
Domain
accountChecklist: