Step configuration

In this section, you will learn how configure steps.

Step style

Most steps have the option to configure the StepStyle.

Style	Default	Description
`Suspend`	Yes	Step will suspend the execution of the command until the step receives updates or is completed in a final state, saving on resources.
`WaitUntil`	No	The step will wait until the step is completed in a final state, the step will not receive intermediate updates. Use this style if the command benefits from being kept in memory.

Each kind of step has a default StepStyle:

Steps in the style of WaitUntil can be suspended when a retry in scheduled due to a case of failure or timeout.

In case of Run inline, the step will retry inline if the retry timeout is less then InlineStepRetryDelayThresholdSec.

Configures whether intermediate progress and output results are tracked use StepTrackingOptions.

Options	Default	Description
TrackProgress	true	Track intermediate progress (eg. % of tasks done)
TrackIntermediateResults	true	Track intermediate results (eg. finished tasks), can be turned of for efficiency.

Steps have the option to pass in the maxDuration directly, without having to specify a StepExecutionOptions argument.

The Run inline step can specify StepExecutionOptions to have further control how the step is executed:

Property	Type	Required	Description
`DefaultRetryPolicy`	RetryPolicy	No	Default retry policy
`TimeoutRetryPolicy`	RetryPolicy	No	Timeout retry policy
`IntermediateFailureRetryPolicy`	RetryPolicy	No	Intermediate failure retry policy
`FailureRetryPolicy`	RetryPolicy	No	Failure retry policy
`MaxDuration`	long	No	Maximum duration in seconds

The following step status codes are possible:

Status	Description
`Creating`	Step is creating
`Created`	Step is created
`CreationFailed`	Step creation has failed
`Running`	Step is running
`Succeeded`	Step is succeeded
`Timeout`	Step is timed out
`Failed`	Step is failed
`Canceled`	Step is canceled
`IntermediateFailure`	Step has failed in an intermediate state
`Outdated`	Step is outdated

The status codes Succeeded, Timeout, Failed, Canceled and Outdated are considered final states.

The retry policy configures how steps are retried on completion:

Property	Type	Required	Default	Description
`InitialDelaySec`	double	No	15	The delay between retry attempts for a fixed approach or the delay on which to base calculations for a backoff-based approach. If the command provides a retryAfter response, the next retry is delayed by the duration specified by the retryAfter value. (Default: 15 sec, max 7 days).
`MaxRuns`	int	No		Max task runs (-1: unlimited, 0: single execution attempt, no retry, >= 1: total number of attempts/retries).
`MaximumDelaySec`	double	No	60	The maximum delay between retry attempts when the command doesn't provide a retryAfter response. If the service provides a retryAfter response, the next retry is delayed by the duration specified by the header value. (default 60 sec, max 7 days).
`RetryMode`	RetryMode	No	Exponential	Method to calculate retry delays (default: Exponential).

Policy	InitialDelaySec	MaxRuns	MaximumDelaySec	RetryMode
DefaultRetryPolicy	2	0	60	Exponential
TimeoutRetryPolicy	2	0	60	Exponential
IntermediateFailureRetryPolicy	2	10	60	Exponential
FailureRetryPolicy	2	0	60	Exponential

Policy	InitialDelaySec	MaxRuns	MaximumDelaySec	RetryMode
DefaultRetryPolicy	15	0	3600	Exponential
TimeoutRetryPolicy	15	5	3600	Exponential
IntermediateFailureRetryPolicy	15	10	3600	Exponential
FailureRetryPolicy	15	5	3600	Exponential