softwaremill / softwaremill/ox
Add multi-policies for retries
Nobody has claimed this yet.
- Dominant language
- Scala
- Stars
- 522
- Forks
- 35
- Avg merge
- 45m
- Merged PRs (30d)
- 13
Description
The current retry mechanism only supports a single retry policy for a successful/erroneous result of a given operation, which can only be customized by providing a ResultPolicy that allows for re-defining success or failing fast on given errors. The limitation of this approach is that it doesn't support different retry strategies for different types of errors.
We'd like to be able to define a multi-policy, i.e. one that assigns different retry strategies to different errors, so that e.g. we retry immediately for some errors, but use exponential backoff for others.
A multi-policy could be thought of as a total function E => RetryPolicy, where E is the error type for the operation, e.g.
sealed trait Error
object Error:
case class WithCode(code: Int) extends Error
case object Other extends Error
val policy = MultiPolicy {
case Error.WithCode(code) if code == 42 => RetryPolicy.immediate(3)
case Error.WithCode(_) => RetryPolicy.delay(4, 1.second)
case Other => RetryPolicy.backoff(5, 100.millis)
}
One thing to consider is whether we want a notion of "failing fast" within the multi-policy - since it can already be handled by a ResultPolicy(isWorthRetrying = _ => false). Allowing to define it within a multi-policy as well - although possibly useful - might introduce ambiguity.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the current retry mechanism and ResultPolicy implementation. Define how a MultiPolicy maps each operation error to a retry strategy, including whether failing fast belongs inside the multi-policy or remains a ResultPolicy concern. Done means different errors can select immediate, delayed, or backoff strategies as described in the examples.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100