Failure detection - Ruby SDK

This page shows how to do the following:

• Workflow timeouts
• Workflow retries
• Activity timeouts
• Activity Retry Policy
• Heartbeat an Activity
• Heartbeat Timeout

Workflow timeouts

Each Workflow timeout controls the maximum duration of a different aspect of a Workflow Execution.

• Workflow Execution Timeout: Limits how long the full Workflow Execution can run.
• Workflow Run Timeout: Limits the duration of an individual run of a Workflow Execution.
• Workflow Task Timeout: Limits the time allowed for a Worker to process a Workflow Task.

Set these values in the WorkflowOptions when starting a Workflow.

Workflow retries

Use a Retry Policy to automatically retry Workflow Executions on failure. Workflow Executions do not retry by default.

Activity timeouts

Each Activity Timeout controls a different aspect of how long an Activity Execution can take:

• Schedule-To-Close Timeout
• Start-To-Close Timeout
• Schedule-To-Start Timeout

At least one of StartToCloseTimeout or ScheduleToCloseTimeout is required.

Activity Retry Policy

By default, Activities use a system Retry Policy. You can override it by specifying a custom Retry Policy.

Override the retry interval with nextRetryDelay

If you raise an application-level error, you can override the Retry Policy's delay by specifying a new delay.

Heartbeat an Activity

A Heartbeat is a periodic signal from the Worker to the Temporal Service indicating the Activity is still alive and making progress.

• Heartbeats are used to detect Worker failure.
• Cancellations are delivered via Heartbeats.
• Heartbeats may contain custom progress details.

Heartbeat Timeout

The Heartbeat Timeout sets the maximum duration between Heartbeats before the Temporal Service considers the Activity failed.