-
Notifications
You must be signed in to change notification settings - Fork 85
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
Release centrifuge 1024 client 1035 #1607
Conversation
Have you checked how many accounts need to be migrated? I dont think its realistic to do this in a single block migration. Why dont we use Parity's script? |
0fc419e
to
0654dac
Compare
hex::encode(previous_key.clone()) | ||
); | ||
|
||
/// The difference between the old and new account data structures |
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.
Tested by running:
./target/debug/centrifuge-chain try-runtime --runtime target/debug/wbuild/centrifuge-runtime/centrifuge_runtime.wasm --chain centrifuge on-runtime-upgrade live --uri wss://fullnode.centrifuge.io:443
Some entries decode without any issues, however, the majority fail when decoding to both old and new, also with "unexpected" values, as per the checks listed below.
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.
After running the above, using the live centrifuge chain, the total number of account keys processed was - 102015.
cc @wischli
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 suppose that number reflects the decodable acocunts? I'd be interested in the accounts with reserved
and/or frozen
balance.
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.
We can add those as well, I'm concerned with the accounts that fail to decode into the old structure, I wasn't expecting that tbh.
Some(old) => { | ||
if !old.data.fee_frozen.is_zero() { | ||
log::warn!("Balances Migration - Old account data with non zero frozen fee") | ||
} |
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.
If we eventually apply this migration, we should return counters for frozen and reserved accounts and check against these in post_upgrade
.
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.
No migration to be applied here from what I understand.
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.
// * Research whether we need to migrate locks in orml (maybe first check if | ||
// there exist any. ^^ |
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.
orml-tokens
has not updated their AccountData
yet:
https://github.com/open-web3-stack/open-runtime-module-library/blob/8f59b50ab45d15572d18cee0425966e43567a954/tokens/src/lib.rs#L142-L160
I would assume, they won't do that to not force consumers into synchronous migrations. In Substrate, the misc_frozen
field of AccountData
was replaced with flags
. However, both fields have the same size which removes the requirement of a sync migration: https://github.com/paritytech/substrate/pull/12951/files#r1140113642
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.
Yup, just thought that it might be a good idea to have similar checks like we do for the normal accounts. No actual migrations taking place, just us having some checks before the upgrade itself. WDYT?
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 think that is a good idea!
// TEST ACCOUNT DATA - START | ||
let test_account_data = get_test_account_data::<T>(); | ||
|
||
for (account_id, account_data) in test_account_data { |
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.
@mustermeiszer @wischli do you think this should suffice or should we add 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.
I think that suffices. Thanks a lot!
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.
Note: on_runtime_upgrade
already uses the new WASM sucht that we cannot write the old AccountInfo
. Upgraded the test data to set new AccountInfo
despite having a bit less purpose.
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 was just setting the storage with the raw encoded value of the old account data. How does the WASM version affect this?
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 don't have an answer for you but none of the accounts set during migration could be decoded whereas pre-existing ones with reserved
or misc_frozen
could. So it didn't simulate a real scenario.
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.
On that note: Putting the raw encoded data for the new AccountInfo also led to decoding issues. I don't have capacity to look into this. Writing via pallet_balances::Account
worked and was sufficient to me given that this is just a testing migration.
* Fix main branch detection for docker build * Try out GHA for Pages deployment * Docker build clean up workflow * publish docker in all non-PR events * fix docs cache (github token) * Deploy docs only from main branch * revert docker build machine size
* fix: blocking transfer debt by epoch and redemptions. * feat: make change_id deterministic * fix: build
Bumps [google-github-actions/auth](https://github.com/google-github-actions/auth) from 1.1.1 to 1.2.0. - [Release notes](https://github.com/google-github-actions/auth/releases) - [Changelog](https://github.com/google-github-actions/auth/blob/main/CHANGELOG.md) - [Commits](google-github-actions/auth@35b0e87...f105ef0) --- updated-dependencies: - dependency-name: google-github-actions/auth dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Guillermo Perez <[email protected]>
let mut previous_key = prefix.clone(); | ||
|
||
while let Some(next) = sp_io::storage::next_key(&previous_key) { | ||
if !next.starts_with(&prefix) { |
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.
Great catch! I also had this initially but removed it since I was trying to use the pallet_balances::Account
prefix and wasn't getting any results... fun times.
chore: bump lock
fix: weights fix: allowlist weights
8fda552
to
52ee34a
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.
Can not approve but looks good!
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.
Proxy-approving for @mustermeiszer
Description
Release candidate for Centrifuge 1024 runtime and v0.10.35 client.
Checklist: