0

The forkless runtime upgrade is an excellent feature! I have searched many documents on runtime upgrade, but no guide found for handling upgrade exceptions or rollback.

The most exception often happens is "Block producing stuck" OR "Same Block Imported again and again"! I know there are many reasons for it.

  1. "build block took too long"
  2. "trouble sending the block"
  3. "Invalid parachain code in the relay"
  4. "trouble verifying the block in time"

So the core question is: How to fix no new block-producing issue caused by runtime upgrade?

Ps. "Took too long" exception case, Our chain block target 12s. Imported #110016 again and again! (use authorizeUpgrade&enactAuthorizedUpgrade for upgrade)

2022-05-25 14:35:36.537  INFO tokio-runtime-worker sc_basic_authorship::basic_authorship: [Parachain] 🎁 Prepared block for proposing at 110016 (28 ms) [hash: 0x51e4bcb83f34a48a0cc05fe79b59fad058736bc2f6e32f90979d2f68eb79762e; parent_hash: 0x4877…ba84; extrinsics (3): [0x371a…3f3b, 0x5696…2d07, 0x3992…fc98]]
2022-05-25 14:35:36.540  INFO tokio-runtime-worker aura: [Parachain] 🔖 Pre-sealed block for proposal at 110016. Hash now 0xd73766b154601ccf8d3cb95c32cda7327e5dbb1473f340acd5aeef530aec34b6, previously 0x51e4bcb83f34a48a0cc05fe79b59fad058736bc2f6e32f90979d2f68eb79762e.
2022-05-25 14:35:36.547  INFO tokio-runtime-worker substrate: [Parachain] ✨ Imported #110016 (0xd737…34b6)
2022-05-25 14:35:36.549  INFO tokio-runtime-worker cumulus-collator: [Parachain] PoV size { header: 0.181640625kb, extrinsics: 729.6669921875kb, storage_proof: 732.60546875kb }
2022-05-25 14:35:36.551  INFO tokio-runtime-worker cumulus-collator: [Parachain] Compressed PoV size: 738.232421875kb
2022-05-25 14:35:36.561  INFO tokio-runtime-worker cumulus-collator: [Parachain] Produced proof-of-validity candidate. block_hash=0xd73766b154601ccf8d3cb95c32cda7327e5dbb1473f340acd5aeef530aec34b6
2022-05-25 14:35:36.794  INFO tokio-runtime-worker substrate: [Parachain] 💤 Idle (1 peers), best: #110015 (0x4877…ba84), finalized #110015 (0x4877…ba84), ⬇ 0 ⬆ 0
2022-05-25 14:35:38.065  INFO tokio-runtime-worker substrate: [Relaychain] 💤 Idle (50 peers), best: #387863 (0xf564…a777), finalized #387859 (0x38af…d76e), ⬇ 196.2kiB/s ⬆ 413.2kiB/s

CodeHash: enter image description here

Reference:

1 Answer 1

3

I would say that once a para is in the process of upgrading, the new validation function will eventually be set, and that should be without any action from your side.

Seems that your para ended up updating the validation code after some extra waiting time - Also I don't see anymore any scheduled upgrade for your para.

As you point out, it can happen that an upgrade takes longer because of the issues listed in this issue, which you have linked too.

#1: trouble sending the block

#2: trouble verifying the block in time

#3: Invalid parachain code in the relay

Seeing that your parachain did upgrade, then I will discard you where hitting issue #3, and if this is due to not sending the block in time or validators don't verifying the code in time I am afraid there is nothing you can do on your side rather than waiting for it to happen.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.