You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
paritytech/polkadot#4457 will impose an additional constraint on upgrading: the parachain won't be able to upgrade to the same code. While this is silly, if attempted, this will most likely break the parachain. Thus parachain-system should protect the users from doing that.
The text was updated successfully, but these errors were encountered:
Why will that break the parachain? Why isn't that just rejected by the relay chain if it doesn't want this? Just send the signal that the upgrade was rejected?
Yeah, this is exactly the problem: the relay-chain will reject such an upgrade. Parachain will break because it won't receive a GoAhead::Abort signal. The relay-chain does not the abort signal because of technical reasons: right now the code structured in such a way, that signals set in schedule_code_upgrade will be removed in note_new_head. I pitched an idea to reverse their order but was told that it is too big of a change.
We can try to work on this issue more, but I figured it would be just easier to forbid this.
paritytech/polkadot#4457 will impose an additional constraint on upgrading: the parachain won't be able to upgrade to the same code. While this is silly, if attempted, this will most likely break the parachain. Thus parachain-system should protect the users from doing that.
The text was updated successfully, but these errors were encountered: