Skip to main content

Temporal Failures reference

A Failure is Temporal's representation of various types of errors that occur in the system.

There are different types of Failures, and each has a different type in the SDKs and different information in the protobuf messages (which are used to communicate with the Temporal Service and appear in Event History).

Temporal Failure​

Most SDKs have a base class that the other Failures extend:

The base Failure proto message has these fields:

  • string message
  • string stack_trace
  • string source: The SDK this Failure originated in (for example, "TypeScriptSDK"). In some SDKs, this field is used to rehydrate the call stack into an exception object.
  • Failure cause: The Failure message of the cause of this Failure (if applicable).
  • Payload encoded_attributes: Contains the encoded message and stack_trace fields when using a Failure Converter.

Application Failure​

Workflow and Activity code use Application Failures to communicate application-specific failures that happen. This is the only type of Failure created and thrown by user code.

Throw from Workflows​

Only Workflow errors that are Temporal Failures cause the Workflow Execution to fail; all other errors cause the Workflow Task to fail and be retried (except for Go, where any error returned from the Workflow fails the Execution, and a panic fails the Task). Most types of Temporal Failures automatically occur, like a Cancelled Failure when the Workflow is Cancelled or an Activity Failure when an Activity Fails. You can also explicitly fail the Workflow Execution by throwing (or returning, depending on the SDK) an Application Failure.

If a Workflow raises an exception, it will either be retried, or marked as failed. This is dependent on whether the exception is a Workflow Task Failure or a Workflow Execution Failure.

Workflow Task Failures​

A Workflow Task Failure is an unexpected situation failing to process a Workflow Task. This could be triggered by raising an exception in your Workflow code. Any exception that does not extend Temporal's FailureError exception is considered a Workflow Task Failure. These types of failures will cause the Workflow Task to be retried.

Workflow Execution Failures​

An ApplicationError, an extension of FailureError, can be raised in a Workflow to fail the Workflow Execution. Workflow Execution Failures put the Workflow Execution into the "Failed" state and no more attempts will be made in progressing this execution. If you are creating custom exceptions you would either need to extend the ApplicationError class—a child class of FailureError— or explicitly state that this exception is a Workflow Execution Failure by raising a new ApplicationError.

Throw from Activities​

In Activities, you can either throw an Application Failure or another Error to fail the Activity Task. In the latter case, the error is converted to an Application Failure. During conversion, the following Application Failure fields are set:

  • type is set to the error's type name.
  • message is set to the error message.
  • non_retryable is set to false.
  • details are left unset.
  • cause is a Failure converted from the error's cause property.
  • next_retry_delay is left unset.
  • call stack is copied.

When an Activity Execution fails, the Application Failure from the last Activity Task is the cause field of the ActivityFailure thrown in the Workflow.

Non-retryable​

When an Activity or Workflow throws an Application Failure, the Failure's type field is matched against a Retry Policy's list of non-retryable errors to determine whether to retry the Activity or Workflow. Activities and Workflow can also avoid retrying by setting an Application Failure's non_retryable flag to true.

Setting the Next Retry Delay​

By setting the Next Retry Delay for a given Application Failure, you can tell the server to wait that amount of time before trying the Activity or Workflow again. This will override whatever the Retry Policy would have computed for your specific exception.

Java: NextRetryDelay

Cancelled Failure​

When Cancellation of a Workflow or Activity is requested, SDKs represent the cancellation to the user in language-specific ways. For example, in TypeScript, in some cases a Cancelled Failure is thrown directly by a Workflow API function, and in other cases the Cancelled Failure is wrapped in a different Failure. To check both types of cases, TypeScript has the isCancellation helper.

When a Workflow or Activity is successfully Cancelled, a Cancelled Failure is the cause field of the Activity Failure or "Workflow failed" error.

Activity Failure​

An Activity Failure is delivered to the Workflow Execution when an Activity fails. It contains information about the failure and the Activity Execution; for example, the Activity Type and Activity Id. The reason for the failure is in the cause field. For example, if an Activity Execution times out, the cause is a Timeout Failure.

Child Workflow Failure​

A Child Workflow Failure is delivered to the Workflow Execution when a Child Workflow Execution fails. It contains information about the failure and the Child Workflow Execution; for example, the Workflow Type and Workflow Id. The reason for the failure is in the cause field.

Timeout Failure​

A Timeout Failure represents the timeout of an Activity or Workflow.

When an Activity times out, the last Heartbeat details it emitted is attached.

Terminated Failure​

A Terminated Failure is used as the cause of an error when a Workflow is terminated, and you receive the error in one of the following locations:

  • Inside a Workflow that's waiting for the result of a Child Workflow.
  • When waiting for the result of a Workflow on the Client.

In the SDKs:

Server Failure​

A Server Failure is used for errors that originate in the Temporal Service.