//! The pallet takes care of executing a batch of multi-step migrations over multiple blocks. The
//! This example demonstrates a simple mocked walk through of a basic success scenario. The pallet
//! succeeding after two steps. A runtime upgrade is then enacted and the block number is advanced
//! The API contains some calls for emergency management. They are all prefixed with `force_` and
//! Migrations are provided to the pallet through the associated type [`Config::Migrations`] of type
//! points to the currently active migration and stores its inner cursor. The inner cursor can then
//! once it encounters an error (Goal 4). Once in the stuck state, the pallet will stay stuck until
//! As soon as the cursor of the pallet becomes `Some(_)`; [`MultiStepMigrator::ongoing`] returns
//! In `on_initialize` the pallet will load the current migration and check whether it was already
//! migrations are skipped without causing an error. Each successfully executed migration is added
//! This proceeds until no more migrations remain. At that point, the event `UpgradeCompleted` is
//! This function wraps the inner `step` function into a transactional layer to allow rollback in
//! Weight limits must be checked by the migration itself. The pallet provides a [`WeightMeter`] for
//! that purpose. The pallet may return [`SteppedMigrationError::InsufficientWeight`] at any point.
//! process becomes `Stuck`. Otherwise, one re-attempt is executed with the same logic in the next
//! block (Goal 3). Progress through the migrations is guaranteed by providing a timeout for each
//! migration via [`SteppedMigration::max_steps`]. The pallet **ONLY** guarantees progress if this
//! Every now and then, governance can make use of the [`clear_historic`][Pallet::clear_historic]
//! call. This ensures that no old migrations pile up in the [`Historic`] set. This can be done very
//! rarely, since the storage should not grow quickly and the lookup weight does not suffer much.
//! Another possibility would be to have a synchronous single-block migration perpetually deployed
//! [`max_steps`][SteppedMigration::max_steps], are error tolerant, check their weight bounds and
//! 3. Cleanup as described in the governance scenario be executed at any time after the migrations
//! Failed upgrades cannot be recovered from automatically and require governance intervention. Set
//! [`FailedMigrationHandler::failed`] should be setup in a way that it allows governance to act,
//! but still prevent other transactions from interacting with the inconsistent storage state. Note
//! that this is paramount, since the inconsistent state might contain a faulty balance amount or
//! implement this would be to use the `SafeMode` or `TxPause` pallets that can prevent most user
//! migration must be removed and fixed manually. This already applies, even before considering the
//! stuck case the state is already messed up. This just prevents it from becoming even more messed
/// The default number of entries that should be cleared by a `HistoricCleanupSelector::Wildcard`.
/// The caller can explicitly specify a higher amount. Benchmarks are run with twice this value.
pub TestMaxServiceWeight: Weight = <<TestDefaultConfig as frame_system::DefaultConfig>::BlockWeights as Get<BlockWeights>>::get().max_block.div(2);
defensive!("integrity_test ensures that all identifiers' MEL bounds fit into CursorMaxLen; qed.");
defensive!("The integrity check ensures that all cursors' MEL bound fits into CursorMaxLen; qed");