[WIP]: Update Scheduler to Support Relay Chain Block Number Provider #3970 #6362
Conversation
| @@ -1157,24 +1181,30 @@ impl<T: Config> Pallet<T> { | |||
| return | |||
| } | |||
|
|
|||
| let mut incomplete_since = now + One::one(); | |||
| let mut when = IncompleteSince::<T>::take().unwrap_or(now); | |||
There was a problem hiding this comment.
Can you explain why would not it work with IncompleteSince, without the block Queue?
How we determine the MaxScheduledBlocks bound?
With the IncompleteSince we iterate over blocks that might have no task to execute and this might make a situation with many incomplete blocks even worth. But probably not too much? One more read?
Both solutions need a strategy for a situation when there are two many tasks that can not be completed and the task queue only grow. If such strategy not yet in place.
There was a problem hiding this comment.
With the
IncompleteSincewe iterate over blocks that might have no task to execute and this might make a situation with many incomplete blocks even worth. But probably not too much? One more read?
Yes, but then this becomes unbounded in case too many blocks are skipped. The idea behind using the Queue is to bound this to a sufficient number.
How we determine the MaxScheduledBlocks bound?
This should be determined similar to the existing MaxScheduledPerBlock?
Both solutions need a strategy for a situation when there are two many tasks that can not be completed and the task queue only grow. If such strategy not yet in place.
There is already a retry mechanism and the task is purged if the retry count is exceeded (even if failed).
There was a problem hiding this comment.
The Queue not only bounds how many blocks gonna be processed from the past. It bounds for how many blocks we can schedule. If the number is 50, we can schedule only 50 jobs with distinct schedule time.
The MaxScheduledPerBlock for me seems simpler to define. Because the block size its exiting constrain the system have. But how many distinct schedule time points you can have is something new.
Retries work in case if a certain task fails while it's function call is being executed (not the scheduler fail). I meant a case when there are many (or few but too heavy) overdue tasks (task_block < now), so that the scheduler never (or needs too many time) to complete them and exist such overdue state to start processing tasks in time. Do we handle such case?
Step in #6297
This PR adds a Queue to the scheduler pallet that helps in tracking the block numbers with valid agenda. This helps in scheduling the tasks even if the pallet is deployed on a parachain that does not produce blocks on a regular cadence.
Todo