Add retry mechanics to pallet-scheduler#3060
Add retry mechanics to pallet-scheduler#3060georgepisaltu merged 44 commits intoparitytech:masterfrom
pallet-scheduler#3060Conversation
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
|
bot bench-all pallet -v PIPELINE_SCRIPTS_REF=mak-bench-all-pallet --pallet=pallet_scheduler |
|
@mordamax https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5029575 was started for your command Comment |
|
@mordamax Command |
|
bot help |
|
Here's a link to docs |
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
| @@ -1124,11 +1258,17 @@ impl<T: Config> Pallet<T> { | |||
| }, | |||
| Err(()) => Err((Overweight, Some(task))), | |||
There was a problem hiding this comment.
I thought that the task is removed if Unavailable, but now I see that we keep it in the storage. This is why I proposed to remove the retry as well. And also I see now that Overweight does not change it's address.
| if weight | ||
| .try_consume(T::WeightInfo::schedule_retry(T::MaxScheduledPerBlock::get())) | ||
| .is_err() | ||
| { | ||
| Self::deposit_event(Event::RetryFailed { | ||
| task: (when, agenda_index), | ||
| id: task.maybe_id, | ||
| }); | ||
| return; | ||
| } |
There was a problem hiding this comment.
I meant, that it would be better to have this in service_task context. Now the schedule_retry is failable/no-op, which is not clear from service_task context.
There was a problem hiding this comment.
The downside is that you can't know in service_task ahead of time if the task will fail and that it has a retry config. You could check that you can consume the weight anyway, but you might be preventing users from running their tasks when it wasn't necessary.
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
NachoPal
left a comment
NachoPal
left a comment
There was a problem hiding this comment.
LGTM. Just wondering if you considered extending Scheduled struct with RetryConfig fields instead of creating a new Retries storage item. In that way it would natively support retries when schedule() without the need of doing it in two steps (schedule() + set_retry())
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
I considered it but I decided against it. This is a niche mechanic which we don't expect to be widely used right now. Doing it in |
Fixes paritytech#3014 This PR adds retry mechanics to `pallet-scheduler`, as described in the issue above. Users can now set a retry configuration for a task so that, in case its scheduled run fails, it will be retried after a number of blocks, for a specified number of times or until it succeeds. If a retried task runs successfully before running out of retries, its remaining retry counter will be reset to the initial value. If a retried task runs out of retries, it will be removed from the schedule. Tasks which need to be scheduled for a retry are still subject to weight metering and agenda space, same as a regular task. Periodic tasks will have their periodic schedule put on hold while the task is retrying. --------- Signed-off-by: georgepisaltu <george.pisaltu@parity.io> Co-authored-by: command-bot <>
7 participants
Fixes #3014
This PR adds retry mechanics to
pallet-scheduler, as described in the issue above.Users can now set a retry configuration for a task so that, in case its scheduled run fails, it will be retried after a number of blocks, for a specified number of times or until it succeeds.
If a retried task runs successfully before running out of retries, its remaining retry counter will be reset to the initial value. If a retried task runs out of retries, it will be removed from the schedule.
Tasks which need to be scheduled for a retry are still subject to weight metering and agenda space, same as a regular task. Periodic tasks will have their periodic schedule put on hold while the task is retrying.