Scheduler on_initialize supports skipped blocks#8723
Conversation
| // However, if the [`Config::BlockNumberProvider`] is not a local block number provider, | ||
| // then `next_iter_now` could be `now + n` where `n > 1`. In this case, we want to start | ||
| // from `now + 1` to ensure we don't miss any agendas. | ||
| IncompleteSince::<T>::put(now + One::one()); |
There was a problem hiding this comment.
So we basically "abuse" IncompleteSince to just be a cursor that always tracks the next number, yea should work.
There was a problem hiding this comment.
I also considered adding a new storage item like NextBlock, in this case (1) it becomes exactly what is IncompleteSince with this PR changes or (2) it always shows next block from last iteration and we need to manage both storage values, making code a bit more complex.
gui1117
left a comment
gui1117
left a comment
There was a problem hiding this comment.
This PR is good to me.
How can we ensure a similar mistake wasn't made in other pallets when migrating to the different block provider?
Should we re-check them and specifically check that they didn't use the property that block numbers are continuous?
We documented the block number providers in the pallet that they do not support hot-swapping and that it is best to stay with |
I mean for this pallet we didn't document that the block provider must be increasing only by one between blocks. It said:
Which was wrong, the pallet didn't support any difference more than 1 between consecutive blocks, but the doc said it supported any difference that is not "too much". |
Scheduler `on_initialize` supports skipped blocks. Scheduler correctly handles situations where `on_initialize` is invoked with block numbers that: - increase but are not strictly consecutive (e.g., jump from 5 → 10), or - are repeated (e.g., multiple blocks are built at the same Relay Chain parent block, all reporting the same `BlockNumberProvider` value). This situation may occur when the `BlockNumberProvider` is not local - for example, on a parachain using the Relay Chain block number provider. Implementation notes: - The `IncompleteSince` value is always set to the next block `(now + 1)`. - A scheduled task is considered permanently overweight only if it fails during the first agenda processing;
github-project-automation
Bot
moved this from Todo
to Done
in [preview] release tracker
github-project-automation
Bot
moved this from Todo
to Done
in [preview] release tracker
4 participants
Scheduler
on_initializesupports skipped blocks.Scheduler correctly handles situations where
on_initializeis invoked with block numbers that:BlockNumberProvidervalue).This situation may occur when the
BlockNumberProvideris not local - for example, on a parachain using the Relay Chain block number provider.Implementation notes:
IncompleteSincevalue is always set to the next block(now + 1).