Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Give RetryPolicy access to failure/error #506

Open
erikvanoosten opened this issue Jun 25, 2024 · 1 comment
Open

Give RetryPolicy access to failure/error #506

erikvanoosten opened this issue Jun 25, 2024 · 1 comment

Comments

@erikvanoosten
Copy link

We have use case where we want to retry some errors immediately, other errors cause a regular exponential backoff.

Is there currently a way to do this with cats-retry? If not, could this feature be added?
@erikvanoosten
Copy link
Author

erikvanoosten commented Jun 25, 2024 •
edited
Loading

Is this a good work-around?

    def shouldRetryImmediately(t: Throwable): Boolean = ???

    effect
      .retryingOnSomeErrors(
        isWorthRetrying = (t: Throwable) => Async[F].pure(shouldRetryImmediately(t)),
        policy = RetryPolicy(_ => Async[F].pure(PolicyDecision.DelayAndRetry(0.millis))),
        onError = logError,
      )
      .retryingOnAllErrors(policy = ???, onError = logError)
      .void

@cb372 cb372 mentioned this issue Jan 6, 2025
Merged
cb372 added a commit that referenced this issue Jan 9, 2025
@cb372
Dynamic retry policies (#550)
256e847 
Fixes #506.

When asking the retry policy to decide the next step, pass the result of
the last attempt. Depending on the combinator, this could be a value or
an error.

Before:

```scala
case class RetryPolicy[F[_]](
    decideNextRetry: RetryStatus => F[PolicyDecision]
)
```

After:

```scala
case class RetryPolicy[F[_], -Res](
    decideNextRetry: (Res, RetryStatus) => F[PolicyDecision]
)
```

This allows users to implement more exotic retry policies, e.g. choosing
to retry some kinds of error quickly, but using exponential backoff for
others. I've added `RetryPolicies.dynamic` to support that.

All the built-in policies maintain their existing behaviour: they ignore
the action result and decide the next step based on static rules.

This was quite a noisy change because it involved adding a new type
parameter to `RetryPolicy`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@erikvanoosten