-
Notifications
You must be signed in to change notification settings - Fork 710
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
Storage corruption in parachain_system::HostConfiguration
due to async backing params
#4603
Comments
https://github.com/centrifuge/centrifuge-chain/blob/v0.10.39/Cargo.toml looking at this, your runtime is still at
This not being the issue. The value is loaded from storage and fails to be decoded and this prints the error that you posted above. |
I see your point but the error occurs with the WASM compiled on our v1.7.2 branch as stated in the steps to reproduce. So the onchain WASM shouldn't matter as, should it? If it does, then this indicates we will still run into that issue when upgrading from v0.9.43 to v1.7.2 in one runtime upgrade. I would assume the fix to still exist in v1.7.2 without requiring an intermediate update, especially because it is not tied to any manual migration.
Moreover, what is the point of versioning the storage of a pallet if the version is not bumped for any change to the storage? Is this my assumption absolutely infeasible or is this issue and exception?
Thanks. I thought that any storage (sub) item which cannot be decoded, falls back to the default implementation. Has this been true up to some point or always been false? |
I mean I assume that you try the
This should not have happened! We now have the try runtime checks for all the chains in CI to ensure that this does not happen again. In handsight, we should have created a fix and backported it. This should never happen again!
I mean it falls back to the default value. However, the error message would still be printed because it failed to decode the value in the first place. |
Thanks a lot for the quick and direct responses. IIUC, this does not require to write a migration and is just an issue as part of |
Yes this will fix it. When the first block is build with the new runtime, the correct config is set and the issue will not appear anymore. It also has (should) not no influence on your chain. |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/paritytech-update-for-april-2024/7646/5 |
Hi @bkchr, Sorry to jump into this closed discussion, but we at the KILT protocol are currently facing the same issue. We're preparing a runtime release where we update the Polkadot dependencies from 1.0.0 to 1.7.0. Here is our current Cargo.toml. We are using the
When we try to simulate the runtime upgrade in a local parachain setup (Paseo or Rococo as relay chain), the same error occurs, causing the chain to stall. Here are the logs of the parachain: Logs
We are hesitant to continue with the release until we can successfully update the runtime in a local environment. I would appreciate any suggestions and support to help overcome this problem. 🙌 |
Okay, I reviewed the implementations of other parachain teams, and noticed that none of them were implementing the |
Sorry for the late reply.
This should be the problem. Updating your collators before doing the runtime upgrade should fix the issue. |
Thanks for the hint. I introduced a silly bug while updating the client to be compatible with async backing. |
Is there an existing issue?
This issue was already reported in #1978. However, the solution was to upgrade to the latest SDK version.
We experienced this issue as part of our upgrade from SDK v1.1.0 to v1.7.2 which was released in February 2024. The quote is from October 2023. So I don't think that solution is truly feasible.
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
The
AbridgedHostConfiguration
value of theHostConfiguration
storage ofparachain-system
was appended by anasync_backing_params: AsyncBackingParams
field in a5f421e without bumping the storage version and adding a storage migration. SinceAsyncBackingParams
does not deriveDefault
, this leads to storage corruption to the best of my knowledge.I discovered this thanks to the
execute-block
CLI oftry-runtime
during our v1.1.0 -> v1.7.2 SDK update which logs an error for that storage.Steps to reproduce
The text was updated successfully, but these errors were encountered: