I have put a lot of thought into what we should consider when performing a runtime upgrade.
Although there is no definitive guide for this, I currently use try-runtime to identify any potential code issues that may cause panic during on_initialize/on_runtime_upgrade.
Additionally, I include some assertions within the try-runtime block to monitor state changes.
A few months ago, I introduced the subalfred checkers in the Substrate seminar and recently published their GitHub actions. Users can now easily integrate these checkers into their repository/CI using:
What are your thoughts on this? How can we improve it?
Apart from this, what other measures can we take to minimize potential errors and ensure a successful runtime upgrade?
6 Likes
I like the feature checked – I recall that often times, having a missing /runtime-benchmarks feature could lead to some nasty compiler errors.
But if you are already going cargo check --features try-runtime --features runtime-benchmarks, would these bring any additional checks?
I brought this up in Detect storage migration requirements in CI · Issue #13125 · paritytech/substrate · GitHub.
1 Like
Yes definitely. I wrote something similar because I was so annoyed with Rust. It can check forward feature propagation and find unintentional feature enabling: README.
It is a big buggy currently, but want to fix it up so that it would work every time.
This check is performed by analyzing of the cargo metadata. Therefore, building any features will not affect the result.