Different retry algorithm for activities

Community Support
1

I have been going through the temporal go developers guide.
One thing I noticed in the “Activity and Workflow Retries” section is that temporal currently supports exponential backoff retry policy.
However, for our use cases, we wanted to explore options on how to add custom retry policies that suites our business requirement.
e.g. one of the policies could be a hybrid policy where the first few attempts are at regular intervals (a little more aggressive) and switch to exponential backoff after a threshold, to avoid overwhelming the systems involved.

  1. I would want to understand if there is any way to enforce this in temporal workflow currently?
  2. Is there any plan for extending retry policies to more algorithms than what we have currently say exponential backoff with jitter, random interval, etc. ?
2

I would model this as two activity invocations. The first with the aggressive retry options and the second (invoked only if the first one fails) with the exponential ones.

You can wrap this pattern in a reusable piece of code.

3

Thanks for the quick response. Are there any future plans to provide support for different retry policies?

4

Temporal activities are invoked through a task queue. Each worker allows specifying limits like a number of parallel activities and maximum activity execution rates. These are much better mechanisms “to avoid overwhelming the systems involved” than retry options.

1 Like