Introduce cancel_proposal to rid us of those pesky proposals#7111
Conversation
Also fix proposal weight.
joepetrowski
left a comment
There was a problem hiding this comment.
Breaks transaction_version in case that hasn't been updated for the next release.
| /// Maximum number of votes reached. | ||
| MaxVotesReached, | ||
| /// The provided witness data is wrong. | ||
| InvalidWitness, |
There was a problem hiding this comment.
self/random note that some other modules can generally use this terminology: Some data that is passed in for sanity/weight should be called witness data.
shawntabrizi
left a comment
There was a problem hiding this comment.
Other than my comments, this looks good.
|
@kianenigma @thiolliere @shawntabrizi ready for final review... |
|
@kianenigma @shawntabrizi would be good to get a final review. |
|
Missing reads and writes. I am investigating |
There was a problem hiding this comment.
I pushed the latest Weights to the PR. Note that the only relevant changes was an additional read to the propose weight, caused by checking the blacklist, and a reduction in the on_initialize_base weight due to bad benchmarking code.
To clarify the intention, on_initialize_base is supposed to be the least amount of computation needed by the on_initialize code, so in this case (5 + R) Reads.
If the on_initialize code actually triggers any of the more complex paths, like launch_next or bake_referendum, we will assume that the computation should take a full block weight. This is hardcoded into the on_initialize logic.
Tracking Issue: https://github.com/paritytech/substrate/issues/7209
|
bot merge |
|
Trying merge. |
Also fixes the weight of
proposeand introduces a hard-coreblacklistoption to ensure a proposal hash never returns.polkadot companion: paritytech/polkadot#1728
TODO: