How does a retry policy impact the activity timeouts?

I would like to understand the impact and/or correlation between activity options and a retry policy. At the moment, I assume that the activity options I use to execute an activity in a workflow are for a single execution of the activity. When setting a retry policy, again I assume that on retry the same activity options are used.

Are my assumptions correct?

2 Likes

Hey, great question. There is a bit more nuance in the way things work. There are three timeout options for activities:

  • ScheduleToStart - Maximum time a Workflow should wait for a Worker to start executing the Activity. This is commonly used for checking if all workers are down or are not able to keep up with current request rate.
  • StartToClose - Maximum time an Activity can take to execute after it was picked by a Worker. If this is exceeded the Activity will be retried.
  • ScheduleToClose - Maximum time from when the Workflow requests an Activity execution to its completion including retries

As you can see, one of the options StartToClose functions on a per-retry basis while ScheduleToClose takes all retries into account. If your ScheduleToStart timeout is exceeded, the activity will not be retried. I hope this clears things up :slight_smile:

2 Likes