-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[runtime 9122] panicked at 'Externalities not allowed to fail within runtime: DefaultError' #4232
Comments
Means that the storage proof was probably missing some data. |
@bkchr what shall I do to fix it? today I've been working on runtime upgrade tests for our dot auction, but it always fails I've had this error, and the parachain cannot produce blocks anymore after doing runtime upgrade |
We run into the same issue. The runtime upgrade didn't include any significant changes. We where already upgrades to 0.9.12. The logs show:
Relay chain: westend runtime 9122 and client 0.9.12 |
@weichweich can you give me the 0.9.11 based branch? Then I can try to run your parachain and upgrade to the given 0.9.12 based release. |
@bkchr Our runtime with 0.9.11 was version 1.1.0 (https://github.com/KILTprotocol/mashnet-node/tree/1.1.0, 5209c7a19150f5033477f148a8329f711441a543) Now we are testing version 1.2.0 which fails. https://github.com/KILTprotocol/mashnet-node/tree/master |
Ahh, so you are already on the 0.9.12 branch? And update 1.1.1 worked? But another upgrade, that uses the 0.9.12 branch is failing? Is that correct? |
yes! The upgrade to 1.1.1 (with version 0.9.12) worked on all testnets (we will upgrade to it today on our live net). |
I also just noticed that my error happens in a different line. 🤔 |
@weichweich where is it failing for you? |
/cargo-home/git/checkouts/substrate-7e08433d4c370a21/d76f399/primitives/state-machine/src/ext.rs:201:58 |
The best way to check whether the relay chain and the parachain synchronized the code upgrade correctly are to check the state of the paras module in the relay chain and compare to the value of If they're desynced, there's either a bug in the paras pallet or parachain-system in Cumulus, depending how you look at it. And that'd definitely cause a stall. I wonder if it also could be that the pvf Executor doesn't provide all host functions to the pvf. |
@rphmeier |
can confirm, Parachain's whereas on relay-chain |
ok, here is the reconstruction what happened: On the parachain the last block is 329,958. The relay-parent of that block is 1,338,953. The upgrade was scheduled by parablock 329,943 (relay-parent=1,338,923). From what I see 329,958 had to enact upgrade but did not. I make this conclusion looking at the sequence of events of the relay-chain, which seems to be working correctly: (from most recent to least recent)
|
Your parachain is registered on the relay chain with ID 2001 but believes itself to be para 2000. This breaks the upgrade go-ahead signal code because it reads the signal for para 2000 instead of the signal for para 2001. The relay chain believes that the parachain has read the signal and will upgrade, whereas the parachain does not act on it and then bricks. |
@rphmeier ok I just found that our submitted genesis is using wrong parachain id, didn't find it during our tests, I'm very very sad now :( this should be due to one mistake on my side, I'm wondering what can we do to fix this...it's already live on polkadot auction so there are two
will |
it seems that
|
@GopherJ Governance should be able to update the storage in the ParachainsInfo pallet to update it to the correct value. |
@bkchr do we need a separate issue for the build-spec cli flag in Cumulus? |
which governance call? on parachain side? I didn't see an extrinsic for changing this |
You can use system::setStorage directly (you can do almost anything with this call if you know what you're doing) |
will try it, thanks |
Yes! Thanks for all the help! We reset the parachain code on the relaychain which let the parachain produce blocks again, fixed the parachain ID, and force-scheduled the runtime upgrade from the relay chain. |
@rphmeier hi, I still have some issues, I tried to to runtime upgrade on a runtime with correct parachain id (2085) but then found that what can this be? do you have an idea? |
@pepyakin yes just found them yesterday |
@rphmeier, I got this same message today in an active paravalidating session on kusama, is it relevant?
There were two bursts in one parachain session this night. Everything seems to work normal after and the session was a grade A so i'm not to worried. |
Interestingly, this does not seem to be an error coming from the polkadot node. From here it is not clear what emits this log message. Could it be emitted by a parachain? |
i'm running the default apt binary
|
Yes it is coming from a Parachain. For the relay chain, we don't use this code from inside wasm. @stakeworld you can ignore this. |
I encounterred this error in relaychain side while doing runtime upgrade for a parachain
The text was updated successfully, but these errors were encountered: