Handle errors in Serverless Workflow task steps-CloudFlow(CloudFlow)-阿里云帮助中心

Serverless workflow integrates with multiple Alibaba Cloud services. When cloud services serve as execution nodes of task steps in Serverless workflow, configure retry and catch policies to handle execution errors and stabilize tasks in production.

Error handling methods

Task steps in Serverless workflow support error catching with retry or redirect actions. For more information, see Task steps.

Retry a task after an error is caught.

steps:
  - type: task
    name: hello
    resourceArn: acs:fc:{region}:{accountID}:xxx
    retry:
      - errors:
          - FnF.ALL
        intervalSeconds: 10
        maxIntervalSeconds: 300
        maxAttempts: 3
        multiplier: 2

Table 1. Parameters for retrying a task after an error is caught
Parameter	Description
`retry`	Retries the task when an error is caught.
`errors`	Errors to catch.
`intervalSeconds`	Initial retry interval in seconds. Maximum: 86400. Default: 1.
`maxAttempts`	Maximum retry attempts. Default: 3.
`multiplier`	Multiplier applied to the retry interval after each attempt. Default: 2. In the sample code, the second retry runs after 20 seconds and the third after 40 seconds.

Redirect a task after an error is caught.

steps:
  - type: task
    name: hello
    resourceArn: acs:fc:{region}:{accountID}:xxx
    errorMappings:
      - target: errMsg
        source: $local.cause # This value is reserved for the system and can be directly used when an error occurs in this step. 
      - target: errCode
        source: $local.error # This value is reserved for the system and can be directly used when an error occurs in this step. 
    catch:
      - errors:
        - FnF.ALL
        goto: final

Table 2. Parameters for redirecting a task after an error is caught
Parameter	Description
`errorMappings`	Error fields from this step to pass during redirection.
`catch`	Error catch policy for the task.
`errors`	Errors to catch.
`goto`	Target step to redirect to when the task throws an error.

Function Compute errors in Serverless workflow

When Function Compute serves as an execution node of a task in Serverless workflow, two error types can occur:

Exceptions prompted by Function Compute
Function code errors

Catch these errors by specifying errors in a task in Serverless workflow.

Common system errors prompted by Function Compute or Serverless Workflow

Common error types:

- errors:
  - FC.ResourceThrottled
  - FC.ResourceExhausted
  - FC.InternalServerError
  - FC.Unknown
  - FnF.TaskTimeout
  - FnF.ALL

Table 3. Common error types
Error type	Description
`FC.{ErrorCode}`	Function Compute returns a non-200 HTTP status code. Common types: `FC.ResourceThrottled`: Functions throttled due to high concurrency. The total concurrency limit is shared across all invocation methods, including Serverless workflow task nodes. You can request a limit increase. `FC.ResourceExhausted`: Functions throttled due to insufficient resources. Contact us when this error occurs. `FC.InternalServerError`: Internal Function Compute error. Re-execute the flow. Note `{Error code}` is the Function Compute error code. For more information, see Error codes.
`FC.Unknown`	Function Compute invoked the function, but an uncaught error occurred during execution. Example: `UnhandledInvocationError`.
`{CustomError}`	Function Compute invoked the function, but the function threw an exception.
`FnF.TaskTimeout`	A step in Serverless workflow timed out.
`FnF.ALL`	Catches all errors in Serverless workflow.
`FnF.Timeout`	The overall flow execution in Serverless workflow timed out.

Custom error types

Beyond built-in Function Compute and Serverless workflow errors, you can define custom error types. Throw an exception in your function code to pass the error state to Serverless workflow. Serverless workflow then retries or redirects based on the flow definition. The following Python example defines a custom error type and configures retry in Serverless workflow:

Define a custom error type in your function code.

...
class ErrorNeedsRetry(Exception):
    pass
  
def handler(event, context):
    try:
        # do sth
    except ServerException:
        raise ErrorNeedsRetry("custom error message")

Configure the task step in Serverless workflow to catch and retry the error.

retry:
  - errors:
      - ErrorNeedsRetry
  intervalSeconds: 10
  maxAttempts: 3
  multiplier: 2

Other cloud services as task execution nodes

When a third-party cloud service serves as a task execution node, Serverless workflow calls the service API directly to distribute the task.

For example, when MNS serves as the execution node, Serverless workflow calls the SendMessage operation to send messages. For more information, see SendMessage. These API-based tasks typically do not return execution results. After an error is caught, Serverless workflow retries up to the specified number of times. For services like MNS and Visual Intelligence API, you do not need to handle errors in the flow.