CloudFlow:Error handling

Overview

Expected or unexpected errors may occur during the workflow integration of CloudFlow. In this case, you can continue to operate the current state or move to the next state. The FnF.ALL keyword is a special option that catches all errors. You can use the retry and catch policies to handle errors. For more information, see Retry and Catch.

The states that support error handling

You can use the Retry and Catch fields in the definition of the following states to specify the retry and catch policies and handle errors in the states.

• Task

• Parallel

• Map

Retry

Catch

The OutputConstructor parameter is used together with the Next parameter. If an error occurs in a state, no expected outputs are generated in the state. The workflow cannot proceed even if the workflow transits to the next state. In this case, you can use the OutputConstructor parameter to construct an output and use the output as the input for the next state to which the workflow transits.

Common error types

The following common error types occur when CloudFlow is integrated with Function Compute. For information about the error types that occur when CloudFlow is integrated with other cloud services, see the corresponding service integration documentation.

Examples of common error handling

• Basic retries

• Backoff retries

• Complex retry policies

Basic retries

In this example, if an error occurs and hits the MyCustomException1 retry policy during the service integration invocation named my-error-handle-example, the system attempts up to three retries based on the retry policy. After the three retry attempts are exhausted, the current error hits the MyCustomException1 catch policy. The system constructs a custom error output by using the OutputConstructor parameter and uses the custom error output as the input for the ErrorCatchExit state. Then, the workflow transits to the ErrorCatchExit state.

Type: StateMachine
Name: ErrorHandleExample
SpecVersion: v1
Description: an example of basic error handling
StartAt: my-error-handle-example
States:
  - Type: Task
    Name: my-error-handle-example
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST
      invocationType: Sync
      body: |
        xxx
    Retry:
      - Errors:
          - MyCustomException1
        Description: retry policy 1
        MaxAttempts: 3
        IntervalSeconds: 2
    Catch:
      - Errors:
          - MyCustomException1
        Description: catch policy 1
        OutputConstructor:
          ErrorCode: MyCustomException1
          ErrorMessage: MyCustomException1
        Next: ErrorCatchExit
    Next: SucceededExit
  - Type: Pass
    Name: ErrorCatchExit
    End: true
  - Type: Pass
    Name: SucceededExit
    End: true

Before you save the YAML configuration file, you must verify the validity of resourceArn. Replace resourceArn in resourceArn:acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST by using your actual function ARN. For more information about how to obtain the ARN of a function, see Obtain the ARN of the function.

• regionId: the ID of the region where your function resides, such as cn-beijing or cn-hangzhou.

• accountId: the ID of your Alibaba Cloud account.

• myfunction: the name of your function.

• LATEST: the version of the function. You can replace LATEST with a specific version or alias based on your business requirements.

MyCustomException 1: You can modify the error message based on your business requirements.

Backoff retries

In this example, if an error occurs and hits the MyCustomException2 or MyCustomException3 retry policy during the service integration invocation named my-error-handle-example, the system attempts up to three retries based on the retry policy. The initial retry interval is 5 seconds. The system attempts retries at intervals of 5, 10, 20, and 40 seconds based on the backoff rate 2.0. After the three retry attempts are exhausted, the current error hits the MyCustomException2 or MyCustomException3 catch policy. The system constructs a custom error output by using the OutputConstructor parameter and uses the custom error output as the input for the ErrorCatchExit state. Then, the workflow transits to the ErrorCatchExit state.

Type: StateMachine
Name: ErrorHandleExample
SpecVersion: v1
Description: an example of backoff error handling
StartAt: my-error-handle-example
States:
  - Type: Task
    Name: my-error-handle-example
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST
      body: xxx
    Retry:
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: retry policy 2
        MaxAttempts: 3
        IntervalSeconds: 5
        BackoffRate: 2.0
    Catch:
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: catch policy 2
        Next: ErrorCatchExit
    Next: SucceededExit
  - Type: Pass
    Name: ErrorCatchExit
    End: true
  - Type: Pass
    Name: SucceededExit
    End: true

Complex retry policies

In this example, a retry policy and a catch policy are specified for the FnF.ALL error type. If an error other than MyCustomException1, MyCustomException2, and MyCustomException3 occurs during the service integration invocation named my-error-handle-example, the system attempts up to three retries based on the retry policy. The initial retry interval is 5 seconds. The last backoff interval based on a backoff rate of 2.0 is 40 seconds. However, the maximum backoff interval is set to 30 seconds. The system attempts retries at intervals of 5, 10, 20, and 30 seconds. After the three retry attempts are exhausted, the current error hits the FnF.ALL catch policy. No custom error output is constructed by using the OutputConstructor parameter. By default, the workflow transits to the ErrorCatchExit state.

Type: StateMachine
Name: ErrorHandleExample
SpecVersion: v1
Description: an example of error handling
StartAt: my-error-handle-example
States:
  - Type: Task
    Name: my-error-handle-example
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST
      body: xxx
    Retry:
      - Errors:
          - MyCustomException1
        Description: retry policy 1
        MaxAttempts: 3
        IntervalSeconds: 2
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: retry policy 2
        MaxAttempts: 3
        IntervalSeconds: 5
        BackoffRate: 2.0
      - Errors:
          - FnF.ALL
        Description: retry policy 2
        MaxAttempts: 3
        IntervalSeconds: 5
        BackoffRate: 2.0
        MaxBackoffSeconds: 30
    Catch:
      - Errors:
          - MyCustomException1
        Description: catch policy 1
        OutputConstructor:
          ErrorCode: MyCustomException1
          ErrorMessage: MyCustomException1
        Next: ErrorCatchExit
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: catch policy 2
        Next: ErrorCatchExit
      - Errors:
          - FnF.ALL
        Description: catch policy 3
        Next: ErrorCatchExit
    Next: SucceededExit
  - Type: Pass
    Name: ErrorCatchExit
    End: true
  - Type: Pass
    Name: SucceededExit
    End: true