You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like to have a way to use different timeout values between tries depending the thrown exception.
For example: A race condition resulting in DataIntegrityViolationException could be retried after 100ms; while a ServiceUnavailableException might need a little bit more time to recover successfully.
Workaround:
Using setRetryPolicy with different timeouts depending on the exception available inside onRetryableExecution right before the timeout is evaluated.
I can consider adding this if the group feels this is within the scope of the retry core.
This could take the form of a BackOff which selects a delegate based on the last thrown exception as configured using RetryPolicy.Builder (for instance .backOffFor(DataIntegrityViolationException.class, Duration.ofMillis(100)) with the current backoff as fallback). The matching would happen according to exception type inheritance similar to how includes/excludes currently work. In case a different structure would be preferred like a Function<Throwable,Duration> callback, I am open to do that too.
Activity
03hjain commentedon Oct 28, 2026
I can consider adding this if the group feels this is within the scope of the retry core.
This could take the form of a BackOff which selects a delegate based on the last thrown exception as configured using RetryPolicy.Builder (for instance .backOffFor(DataIntegrityViolationException.class, Duration.ofMillis(100)) with the current backoff as fallback). The matching would happen according to exception type inheritance similar to how includes/excludes currently work. In case a different structure would be preferred like a Function<Throwable,Duration> callback, I am open to do that too.
farheen-shaikh0509 commentedon Oct 28, 2026
Hi! I would like to work on this issue. Could I take this up?