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.
Introduce minimal retry functionality as a core framework feature #34716
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
base: main
Are you sure you want to change the base?
Introduce minimal retry functionality as a core framework feature #34716
Changes from 1 commit
baf3703
2424453
9d2866c
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.
In the description of this PR, you state the following.
For future extension, do you envision extending the contract of
RetryPolicy
?If so, how?
If not, how do you envision extending the feature set "with other retry operations"?
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.
How do you envision a user possibly being able to implement a retry policy conditionally based on the actual exception thrown?
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, I don't exclude extending the contract of
RetryPolicy
with anything that we think essential for this first iteration. The list of exceptions to retry/exclude could be part of the retry policy contract.By "can be extended with other retry operations" I was referring to stateful retries. Stateful retries require some sort of context (similar to the one currently in Spring Retry). But instead of overwhelming the
RetryOperations
interface with both stateless and stateful operations, I envision stateful retries to be defined in a specialization ofRetryOperations
(something likeStatefulRetryOperations
with additional methods dealing with a context). I am trying to follow the ISP here, as most users won't probably need stateful retires, and therefore should not be forced to implement those methods. Do you agree?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 pushed a change set that enriches the retry policy with a method that allows user to provide a predicate on the exception and specify the retry condition. I believe a predicate is more flexible than two lists of exceptions to include/exclude as it is currently in Spring Retry.