-
Notifications
You must be signed in to change notification settings - Fork 101
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
Kusama People: Clear judgements #339
Kusama People: Clear judgements #339
Conversation
#[pallet::hooks] | ||
impl<T: Config> Hooks<BlockNumberFor<T>> for Pallet<T> { | ||
#[cfg(feature = "try-runtime")] | ||
fn try_state(_: BlockNumberFor<T>) -> Result<(), sp_runtime::TryRuntimeError> { |
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.
you can run this with
> cargo install --git https://github.com/paritytech/try-runtime-cli --locked
> cargo build -p people-kusama-runtime --features try-runtime
> try-runtime \ 130 ↵
--runtime ./target/debug/wbuild/people-kusama-runtime/people_kusama_runtime.wasm \
execute-block \
--try-state IdentityOps \
live \
--uri wss://kusama-people-rpc.polkadot.io
assert_eq!( | ||
paid_judgement_count, | ||
Self::do_clear_judgement(&account_id, (identity, username)).0 | ||
); |
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.
with this we tests all existing cases where there is some judgement == Judgement::FeePaid(..)
and deposit > reserved
); | ||
} | ||
} else { | ||
assert_eq!(0, Self::do_clear_judgement(&account_id, (identity, username)).0); |
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.
with this we tests all other cases result no change to judgements
let (removed, identity) = Self::do_clear_judgement(&target, identity); | ||
ensure!(removed > 0, Error::<T>::NotFound); | ||
|
||
IdentityOf::insert(&target, identity); |
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.
Yeah, we use a similar pattern in migrations as well.
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.
Why is this not just a migration? We are talking about 82 accounts?
/// Weight calculation for the worst-case scenario of `clear_judgement`. | ||
/// Equal to 1 identity read/write + 1 subs read + 1 reserve balance read. | ||
fn weight_clear_judgement() -> Weight { | ||
<Runtime as frame_system::Config>::DbWeight::get().reads_writes(3, 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.
We need a benchmark. This is a parachain and thus, we need to know the pov_size
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.
Updated with the benchmark function and the weight from the target machine
Listing 82 accounts in migration feels less friendly to me to verify (by reviewer) and to store in the runtime. Also would need to make sure it all will fit into a single block. |
use frame_system::pallet_prelude::*; | ||
use pallet_identity::Judgement; | ||
|
||
type IdentityPallet = pallet_identity::Pallet<Runtime>; |
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.
Why are we using the concrete Runtime
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.
Why not? Generic instead? This is valid only for the scope of this crate.
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 mean the pallet uses Pallet<T>, Error<T>, etc
but still depends concretely on Runtime. Seems a bit inconsistent to me.
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 do not think it will compile without <T>
argument for those types. For the rest where I can I use the actual type for simplicity.
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.
You think it worth generalizing these pallet for consistency?
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 just realised that you are using it a number of other places as well - accessing the Balances pallet and such. So, probably not worth it at this point.
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.
This pallet is meant to be removed by the following release. I do not see a practical reason to generalized it.
let (removed, identity) = Self::do_clear_judgement(&target, identity); | ||
ensure!(removed > 0, Error::<T>::NotFound); | ||
|
||
IdentityOf::insert(&target, identity); |
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.
Yeah, we use a similar pattern in migrations as well.
I have submitted the benchmark code and am waiting for access to generate the weights. Other than what I've mentioned above regarding my reasoning for using a transaction call instead of a storage migration, my personal opinion is that storage migrations are primarily meant to map a pallet's data to a new storage version. When faced with an issue like this, I first consider if it can be solved with a regular transaction call. If you believe this should be done with a migration, please let me know, and I will rewrite it accordingly. |
system-parachains/people/people-kusama/src/weights/pallet_identity_ops.rs
Outdated
Show resolved
Hide resolved
Co-authored-by: Branislav Kontur <[email protected]>
With a transaction you will need a bot or similar that does the job. A migration is (IMO) a cleaner approach here. Especially for such a small runtime upgrade. But if you want to keep it as a transaction and will also ensure that all are migrated, I don't care :D |
Yes, I would prefer to keep it the current way. It is also possible that the static account list that is correct at the moment of the release publication, wont be correct at the moment it will be executed (if you cancel_judgement and request again for example). I am also not sure how to provide a benchmark for such migration. |
I have included for the removal the judgements with |
How is this possible? Even if the registrar had a fee of zero, wouldn't the status change from |
Yes, it did receive the actual judgement from registrar, and transferred all it's reserved balance to registrar. |
it was not zero. but when the judgement is provided, it uses |
Review required! Latest push from author must always be reviewed |
/merge |
cede94a
into
polkadot-fellows:main
Enabled Available commands
For more information see the documentation |
Clear requested judgements that do not have corresponding deposits reserved.
These judgements exist because the data migration did not take into consideration the deposits for requested judgements.
More info: #315 (comment)