Workflow.retry that takes a function to decide if retry is needed

Is your feature request related to a problem? Please describe. Workflow.retry RetryOptions.doNotRetry is a list of strings. So any exception is converted to a string before matching. In many scenarios, the retry is based on a specific information in a specific exception down the chain or even on some other information within the workflow body.

Describe the solution you’d like An API that takes a function (or lambda) that can execute random user provided logic to decide if retry is needed.

Additional context This only works for retries from the workflow code. The service side retries have to rely on string matching in the current architecture. An activity already can decide itself that the error is not retryable by throwing an non-retryable ApplicationFailure.

[Spikhalskiy]

@niegus We typically don’t provide ETAs for feature requests. Contributions are welcomed, this is a great starter issue.

[niegus]

@Spikhalskiy This feature request comes from this thread: https://community.temporal.io/t/temporal-queue-activities/3095/8 to retry in certain cases, doNotRetryPredicate() could do the trick, but it would require to write negative code 😅

Eg.

doNotRetryPredicate(ex -> !(ex.getCause() instanceof TimeoutFailure && 
               ((TimeoutFailure) ex.getCause()).getTimeoutType() == TimeoutType.TIMEOUT_TYPE_SCHEDULE_TO_START))

IMHO (as a customer of this lib) it would be easier:

retryOnPredicate(ex -> ex.getCause() instanceof TimeoutFailure && 
               ((TimeoutFailure) ex.getCause()).getTimeoutType() == TimeoutType.TIMEOUT_TYPE_SCHEDULE_TO_START)

WDYT? Would that make sense?