Open ggwpez opened 2 weeks ago
Hello @ggwpez, can I work on this issue ?
Yes sure 😄 , please write here if there are Qs coming up.
Yes sure 😄 , please write here if there are Qs coming up.
Thanks I would like to clarify the different steps to enable to access to the migration keys :
SteppedMigration::migrating_prefixes
for the default impl to return empty iteratorSteppedMigrations
, fn nth_migrating_prefixes
to get storage prefixes from the nth migration in the tuplenth_migrating_prefixes
correctly returns storage prefixes for each migration in a tupleMultiBlockMigrationsApi
to expose which storage keys are being modified in the currently running migrationPalletMBM
trait to automatically create storage prefixes from pallet name rather than manual specificationYes sounds good.
Multi Block Migrations can cause chain indexers and explorers to not be able to decode specific storage prefixes since their storage layout is changing. There is currently no way for the outside world to know what keys the runtime is migrating.
One way to achieve this would be to add a function to the
SteppedMigration
trait:This will then be aggregated into the
SteppedMigrations
trait with anth_migrating_prefixes
function that returns the prefix iterator for the nth migration.To expose this information to the public, a Runtime API can be provided (if we dont have view functions then). It would query the
Migrations::Cursor
and then lookup the nth iterator and return all keys into a collected vector.This should not need any modifications to the migrations pallet or frame-executive. Eventually, we can wrap the more pallet-centric aspects of MBMs into a PalletMBM trait and populate this automatically with the pallet prefix.