PR: https://github.com/polkadot-fellows/runtimes/pull/852 ## Context We want to avoid scheduling migration during the last session of an era. We put this hack (https://github.com/polkadot-fellows/runtimes/pull/728) to avoid hitting this issue, by detecting if an election has been kicked off, and stop the migration, needing it to be rescheduled. Given we want to communicate a predictable migration time window to our stake holders, I am afraid this approach might backfire later. For now on Polkadot, last session is between ~ 13:36 and 17:36 CET, so we are safe. Its also unlikely for this window to shift by much, but some factors such as disputes, election issues could technically shift this time window. This could be an issue with Kusama as well given it has much smaller eras (6 hours). ## Issue In Staking, the era transition involves several steps: 1. A snapshot of validators and nominators is taken and an election process is started which is a combination of offchain and onchain computations. 2. Once election is done, staking at the next session boundary, gets the elected set and passes it to session pallet, plus creates some storage items to prep for the next era. Session queues up this validator set, but does not apply it yet. 3. In the next session, session pallet actually applies the validator set, and staking starts the new era. This one session window between step 2 and 3 is the time window we want to avoid to kick off the migration. If migration starts during this time, staking may end up in an inconsistent state. ## Proposed Improvement Instead of the current hacky solution of cancelling migration, I propose we: - Introduce a preparation state in migration, scheduled relative to the migration start time. - This value (prep window) should begin atleast 1 session before, ideally 2 sessions to be safe. - At the start of this preparation window, we set the storage Staking::ForceEra to Forcing::ForceNone which will disable any further elections. This will make the migration more deterministic and give us greater confidence on a predefined migration window.