CloudFlow:Error handling

OutputConstructor

When an error occurs, the failed state produces no output. Without OutputConstructor, the next state receives no input and the workflow cannot proceed meaningfully. Use OutputConstructor to build a structured output that the Next state can consume.

CloudFlow errors

These errors originate from the CloudFlow engine itself.

Function Compute errors

These errors occur when CloudFlow invokes Function Compute. For error types related to other service integrations, see the corresponding service documentation.

Custom errors

Basic retry and catch

This example retries MyCustomException1 up to 3 times at 2-second intervals. If all retries fail, the catch rule constructs custom error output and transitions to ErrorCatchExit.

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

What happens at runtime:

1. The Task state runs FC:InvokeFunction.

2. If MyCustomException1 occurs, CloudFlow retries up to 3 times, waiting 2 seconds between attempts.

3. If all retries fail, the catch rule matches MyCustomException1, constructs output with ErrorCode and ErrorMessage, and transitions to ErrorCatchExit.

4. If no error occurs, the workflow transitions to SucceededExit.

Backoff retry

This example retries MyCustomException2 or MyCustomException3 up to 3 times with exponential backoff. The initial interval is 5 seconds and doubles after each attempt (backoff rate 2.0).

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

Retry timing:

The system attempts retries at intervals of 5, 10, 20, and 40 seconds based on the backoff rate 2.0.

If all retries fail, the catch rule transitions the workflow to ErrorCatchExit. No OutputConstructor is defined here, so the next state receives no custom error output.

Multiple retry and catch policies

This example combines three levels of error handling with different retry strategies:

1. MyCustomException1 -- Retry up to 3 times at fixed 2-second intervals.

2. MyCustomException2 and MyCustomException3 -- Retry up to 3 times with exponential backoff (initial: 5s, backoff rate: 2.0).

3. FnF.ALL (catch-all) -- Retry up to 3 times with exponential backoff (initial: 5s, backoff rate: 2.0), capped at 30 seconds by MaxBackoffSeconds.

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 3
        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

How rule matching works:

CloudFlow evaluates retry and catch rules in the order they appear. For an error that does not match MyCustomException1, MyCustomException2, or MyCustomException3, the FnF.ALL catch-all rule handles it. The FnF.ALL retry uses MaxBackoffSeconds: 30 to cap the interval, so the system attempts retries at intervals of 5, 10, 20, and 30 seconds.

After all retry attempts are exhausted, the corresponding catch rule transitions the workflow to ErrorCatchExit.