-
Notifications
You must be signed in to change notification settings - Fork 47
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
feat: upgrade to Polkadot v0.9.29 #416
Conversation
runtimes/spiritnet/src/lib.rs
Outdated
AuraExt: cumulus_pallet_aura_ext = 24, | ||
Aura: pallet_aura = 23, | ||
Session: pallet_session = 22, | ||
ParachainStaking: parachain_staking = 21, | ||
Authorship: pallet_authorship::{Pallet, Call, Storage} = 20, |
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.
Weirdly, when running benchmarks, an error is thrown with this config under AllPalletsWithSystem
:
Thread 'main' panicked at 'AuRa authorities empty, maybe wrong order in `construct_runtime!`?', /home/willi/.cargo/git/checkouts/cumulus-59522f43471fa161/35dd14f/pallets/aura-ext/src/lib.rs:96
When reverting the order (:= REV
= Authorship -> Staking -> Session -> Aura -> AuraExt), the benchmarks work. That does not make sense though, as we would then run everything in reverse order compared to our current execution. Moreover, there was a user on Discord having problems with REV
and AllPalletsWithSystem
. The issue there was that session keys were not propagated in --dev
environment.
Need to investigate locally...
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 intensive testing, I can say that Aura -> Session -> Staking -> Authorship is fine. However, AuraExt needs to be after Aura because the latter sets the authorities which are queried by AuraExt. Should hopefully be fixed now, see 134d428
@wischli maybe we can wait to see if paritytech/substrate#12351 gets backported into 0.9.29, so that we can push the fix with the next runtime upgrade. |
@wischli the fix has been backported now. So we should update dependencies and test that the new origin fix works. |
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 had few comments that I just noted were pending.
@@ -197,8 +196,8 @@ impl pallet_transaction_payment::Config for Runtime { | |||
} | |||
|
|||
parameter_types! { | |||
pub const ReservedXcmpWeight: Weight = constants::MAXIMUM_BLOCK_WEIGHT / 4; | |||
pub const ReservedDmpWeight: Weight = constants::MAXIMUM_BLOCK_WEIGHT / 4; | |||
pub const ReservedXcmpWeight: Weight = constants::MAXIMUM_BLOCK_WEIGHT.saturating_div(4); |
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 we not saturate here but fail since these are constants?
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 could but I wanted to stay in sync with Parity, see Cumulus
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've seen few PRs where people have pointed out that compilation time should rather panic than silently do something like saturating. Can't find one easily now though. I personally think it would be better not to saturate.
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.
Overflow doesn't panic tho do they? And these are not "consts" in a sense of rust "consts". This gets expanded to a function that returns constants::MAXIMUM_BLOCK_WEIGHT / 4
. So the compiler might optimize that, but he doesn't need to.
The only overflow that can happen while using div is when dividing with -1
anyways and that's not possible since this is a u64. So I actually might also remove the saturating_div.
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 the reason for the saturated div here is that the compiler does not accept just dividing, e.g. it throws cannot call non-const operator in constants
for constants::MAXIMUM_BLOCK_WEIGHT / 4
.
I am unhappy with panicking here. But if you prefer, we can do that.
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.
aha interesting! So it's actually a const function. Didn't look close enough then.
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.
It is a constant hence using a simple /
should be enough, as any invalid case would be caught at compilation time (when compiled in release mode, any overflow or division by zero is also caught). A saturating division would, potentially, saturate without giving any notice. I don't see why we would want to replace a simple division with a saturating one. Or am I missing something else?
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 also don't see a strong case for the saturating_div 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.
Reposting from above:
[... the compiler] throws
cannot call non-const operator in constants
forconstants::MAXIMUM_BLOCK_WEIGHT / 4
.
The issue is that division is currently not implemented for Weight
, on 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.
Oh sorry. Yes I totally didn't get that 🙈! Weight is not a u64 any more and they don't implement that for const. But saturating_div
I was blind but now i can see!
runtimes/standalone/src/lib.rs
Outdated
#[cfg(not(feature = "disable-runtime-api"))] | ||
apis: RUNTIME_API_VERSIONS, | ||
#[cfg(feature = "disable-runtime-api")] | ||
apis: sp_version::create_apis_vec![[]], |
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.
interesting. Do you know why this was added?
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 honestly did not think beyond "yeah maybe we want to be able to disable the runtime API for some testing at some point" since this is part of all relaychain runtimes. However, that has been the case for a long time which I overlooked. So I am perfectly fine with reverting these changes.
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.
@weichweich Should I remove it? Else I would like to merge.
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.
It's standalone so keep it in. We might find a use for it someday. 😂
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.
Its also in the other runtimes 🙈
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.
In that case i wouldn't want something in our spiritnet runtime if we don't have a use case for it. 😰
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.
Removed it for all runtimes in 2560d7a
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.
LGTM
The saturating thing should be resolved so that everyone is happy and I would like to know why the disable-runtime-api
feature was added to the standalone.
* chore: bump deps * wip: migrate pallets and runtimes * chore: bump more versions * wip: fix clients * fix: runtime tomls * style: ignore clippy in default weights * fix: client pt2 * fix: runtimes, clippy * feat: switch pallet execution order * tests: merge delegation from wf-2168-polkadot-v0.9.28 * chore: bump deps to polkadot-v0.9.29 * fix: weights 1.5 for new stuff * fix: cp mistake * fix: update weight templates * fix: pallet order instruction * chore: bump deps * feat: add backported batch fix * refactor: same serde versions * fix: UnitWeightCost type * fix: CI regex for versions * fix: remove disable-runtime-api feat
The order of the pallets during runtime construction has changed. see KILTprotocol/kilt-node#416
The order of the pallets during runtime construction has changed. see KILTprotocol/kilt-node#416
The order of the pallets during runtime construction has changed. see KILTprotocol/kilt-node#416
The order of the pallets during runtime construction has changed. see KILTprotocol/kilt-node#416
The order of the pallets during runtime construction has changed. see KILTprotocol/kilt-node#416
* first iteration: fixes the development-runtime package. * fixed some errors in foucoco runtime. Not yet finished. * new iteration, fixing `foucoco-runtime` * set network to None * fix foucoco runtime and update spacewalk tag * bring back `FungiblesAdapter` * fix amplitude-runtime * fix pendulum-runtime * fix node * cleanup some test build errors * add .lock * fix test build issues * fix test build issues of parachain-staking. The order of the pallets during runtime construction has changed. see KILTprotocol/kilt-node#416 * #242 (comment), #242 (comment), #242 (comment), #242 (comment) * partially fixed test integration test cases * fixed test integration test cases * remove extern crate core * revert comment println * tried to fix the benchmark, but to no avail. * fix benchmark and added weights * add cargo lock * #242 (comment), #242 (comment), * change spec versions * revert version
fixes KILTProtocol/ticket#2200
construct_runtime!
macro because our former traitAllPalletsReversedWithSystemFirst
is now deprecated. To the best of my knowledge, only the staking related pallets have a dependent order which I reversed to replicate the current behaviour. Thanks to the pallet indices, there should be no side effects.Note worthy Substrate PRs
try-runtime
paritytech/substrate#10174AllPallets
and similar types paritytech/substrate#11813T::AccountId
with<T::Lookup as StaticLookup>::Source
paritytech/substrate#11670Checklist:
array[3]
useget(3)
, ...)