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 algorithm for activities Community Support retries	3	1665	January 17, 2022
Temporal Activity Retry Policy Community Support go-sdk , general-impl	1	611	August 17, 2023
How to get retry policy within activity Community Support go-sdk , activity	2	475	May 21, 2024
Questions around activity errors, retry, and more complex error handling scenarios Community Support go-sdk , retries , error-handling	9	3749	July 23, 2021
Different retry options for different kinds of errors Community Support go-sdk	9	658	May 22, 2024

Custom retry policy per error type for activity?

Related topics