Custom retry policy per error type for activity?

maxim · July 7, 2023, 6:51pm

Unfortunately this is not yet supported. Relevant issues:

Different retry options based on failure type

opened 07:38PM - 09 Feb 20 UTC

enhancement API

Currently both workflow and activity retry options do not differentiate between …failure types besides allowing to not retry configured list of failures. The proposal is to allow specifying different retry options for different failure types. For example intermittent errors can be retried immediately, but some errors that are not intermittent (like NPE) and require human intervention can be retried with much higher intervals.

github.com/temporalio/temporal

Use different task queue for activity retries

opened 06:50PM - 07 Jul 23 UTC

mfateev

enhancement

**Is your feature request related to a problem? Please describe.** Some applica…tions require different retry behavior based on error codes. For example ([source](https://community.temporal.io/t/custom-retry-policy-per-error-type-for-activity/8772)): > Hi, we are currently trying to design retry policy for our activity. The activity is calling http server and we want to retry based on the http status code. > > The default for 5xx, it will be retryable with shorter backoff of e.g. 2 sec as these are mostly intermittent. > For 429 (rate limiter) error we want to retry with longer backoff e.g. 1 min. > For 400 error, this might happen because a resource in the server are currently being ‘paused’ by human operator for maintenance. This maintenance is expected to be done < 10 mins, after which the resource is available again. We want to auto retry this request with long backoff e.g. 10 mins. > Other 4xx will NOT be retryable. Providing different retry options will partially help, but for rate limit error changing backoff of an individual activity is not going to help as the aggregate rate across all of them can still be high. **Describe the solution you'd like** Use a different rate limited (possibly with a dynamic rate limiter) task queue to retry activities in certain scenarios. This way retries of activities that failed with a specific error code would be scheduled in a separate task queue. This allows other activities to execute and retry without being limited. The queue might not be directly exposed to a user and be an implementation detail.

Topic		Replies	Views
Different retry options for different kinds of errors Community Support go-sdk	9	803	May 22, 2024
Set Temporal retry options per Exception type Community Support java-sdk	3	620	May 24, 2023
Retrying a workflow for a specific error scenario Community Support	21	5079	February 16, 2024
Questions around activity errors, retry, and more complex error handling scenarios Community Support go-sdk , retries , error-handling	9	4138	July 23, 2021
Activity retries without exception Community Support java-sdk , activity , best-practices	12	4079	August 16, 2023

Custom retry policy per error type for activity?

Related topics