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 1 commit
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.
may be worth mentioning that we talking about possible recoverable fail
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.
My view on this is that we shouldn't mention in the pallet docs what type of calls this applies to because the pallet itself cannot make the distinction between a recoverable or unrecoverable fail. Only a user can do that and they should update their retry config accordingly.
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.
can you explain why you think it should be this way?
the way I think about it, is I want some call to be executed 5 times, and when any of it fail, I wanna retry it 3 times. I wanna be sure that every call will be given chance to be retried 3 times. If first exhausts all retries for some unexpected reason, I do not wanna leave the rest calls without retries. It is hard for me to model such situation.
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 you described it is the way it works.
A periodic task that fails at any point during its periodic execution will have a clone of itself scheduled as a retry. That clone will have a retry configuration attached with
remaining
beingtotal_retries - 1
at first. The original task still has its own unchanged retry configuration. The retry task will keep being retries until it runs out of retries. The periodic task keeps running periodically, potentially spawning other retry clones if it fails again.For non-periodic tasks, there is no clone, they become the retry task because there no point in keeping clones around for something which will never run again.
In short, the point of the doc comment is to say that a retry configuration with
remaining == total_retries
means it's the original task. A retry configuration withremaining < total_retries
means it's a retry clone.I will try to make it clearer in the docs.
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.
Done.
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.