Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add retry mechanics to
pallet-scheduler
#3060Add retry mechanics to
pallet-scheduler
#3060Changes from 5 commits
328d0cd
6f56d9f
22800c5
9315c2e
5bbd31e
3eb8016
9ecae46
fcff15c
a8fd732
3e6e77e
9120d60
4167d6f
816906a
8a28ea5
900d2d5
05cbdfc
5fc62f4
5e305e1
5943dcc
690f2b8
4a81417
438effb
d048760
3c2b540
7a39a69
2e8f954
7dfb517
2e26707
40b567d
2b35465
a43df52
9da58c6
2976dac
8ce66f7
dc9ef2e
945a095
39eb209
2290240
50a2010
e9cc27e
497100c
863bec7
7a16648
b72da0c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way to remove a retry config is just to set it to
0
, or?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We could add 2 more extrinsics to remove a retry config, or we could make
period: Option<BlockNumberFor<T>>
, and unset it in the case ofNone
. I like it how it is now, but I don't feel strongly about this, WDYT?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im also fine with both 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be just worth mentioned in the doc how it can be removed, and make sure we have a unit test for this removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in this and the
Err
arm above you abandon the retry entry if there is any.I would move the retry handling one level above, for this you just need to add for
Ok
varian an info if it failed or not.or at least take it before
execute_dispatch
.please write tests for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
Err
arms above deal with completely different problems:Err(Unavailable)
is a task which may never be able to run and it may never even be attempted againErr(Overweight)
is a task which couldn't run because the scheduler ran out of weight, but it will be run the next time the scheduler services agendas; the scheduler runs agendas from previous blocks if they didn't execute completely, in order of block number from earliest up until presentThis means that an overweight task is not abandoned and will be run again soon, but also that there is absolutely nothing that we can do about it. There is no fallback for the current block if we run out of weight. This is the scheduler's behavior before this PR and I believe the retry mechanism has nothing to do with this.
Most of the logic is common for failed or successful tasks, there would be a lot of copied code. But if you just want to refactor this, I could move the common logic out of the
match
.Tasks are scheduled for retries if they actually run but fail in their execution. By definition, there is no way to handle this before running
execute_dispatch
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 thatOverweight
does not change it's address.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if current iteration for periodic failed and retry scheduled, is not this always
none
?In description you mention that next periodic is placed on hold. What about just letting a user to decide? If a user does not want them overlap, a user controls it with a number of
retries
andperiod
. A user might not want their periodic tasks to be placed on hold, because of retry, to me retry has a lower priority.Also after all retries attempts, it can be too late to schedule next periodic iteration, I think in this case we loose the periodic task.
Without the hold, the logic looks more straightforward to me. As I mentioned in the issue, I think users should assess the possibility of overlapping between a periodic task and retries on their own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that happens, the function exits early here. But there is this corner case where there isn't enough weight to do the retry logic, and in that case retries are ignored, test here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the rest of your comment, I can see why you'd want the period and retry to work independently. I'm ok to make it do this:
I think if we make this behavior configurable (i.e. let users decide which behaviour they want), it would get way too complicated and it's not worth it. I think it's better if it's simpler.
I was trying to avoid this because I saw it as a footgun, but I think you're right. If users set the configurations correctly, it shouldn't be an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposed changes in 9da58c6