-
Notifications
You must be signed in to change notification settings - Fork 86
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
Set correct onchain versions #1796
Conversation
8189052
to
b617f08
Compare
b617f08
to
10fb26e
Compare
I think this changes are not required to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fixes! I suppose pallets are initialized with storage version 0 instead of version at present when added to the runtime..
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1796 +/- ##
=======================================
Coverage 47.70% 47.70%
=======================================
Files 170 170
Lines 13576 13576
=======================================
Hits 6477 6477
Misses 7099 7099 ☔ View full report in Codecov by Sentry. |
But when adding an external pallet, it always starts with the version it has, not 0 🤔 |
Description
I'm not sure why the new Oracle pallets added have their on-chain version of 0 when it should be 1. It is not an issue now, but it can be if we update them tomorrow, and makes the new Ci job for migrations fail. This PR set them with the correct version.
My hypothesis of why this has happened is that we reused the previous indexes from the previous oracle pallets (
orml-oracle
, andpallet-data-collection
), and because of this, it has not update the version (even when the pallet names have changed).The same happens for
Orderbook
andForeignInvestments
foraltair
. Altair didn't require reseting the storage but we did not update the version numbers there.