Skip to main content

​
Overview

Defines the Problem Details RFC compliant description of an error in the Serverless Workflow DSL.

​
Error Object

​
type
uri-template
required
A URI reference that identifies the error type.For cross-compatibility concerns, it is strongly recommended to use Standard Error Types whenever possible.Runtimes MUST ensure that the property has been set when raising or escalating the error.
​
status
integer
required
The status code generated by the origin for this occurrence of the error.For cross-compatibility concerns, it is strongly recommended to use HTTP Status Codes whenever possible.Runtimes MUST ensure that the property has been set when raising or escalating the error.
​
instance
string
A JSON Pointer used to reference the component the error originates from.Runtimes MUST set the property when raising or escalating the error. Otherwise ignore.
​
title
string
A short, human-readable summary of the error or a runtime expression.
​
detail
string
A human-readable explanation specific to this occurrence of the error or a runtime expression.

​
Example

type: https://serverlessworkflow.io/spec/1.0.0/errors/communication
title: Service Not Available
status: 503

​
Standard Error Types

Standard error types serve the purpose of categorizing errors consistently across different runtimes, facilitating seamless migration from one runtime environment to another.

​
Configuration Error

​
type
string
Configuration error type
​
status
integer
default:"400"
Default status code
Description: Errors resulting from incorrect or invalid configuration settings, such as missing or misconfigured environment variables, incorrect parameter values, or configuration file errors.

​
Validation Error

​
type
string
Validation error type
​
status
integer
default:"400"
Default status code
Description: Errors arising from validation processes, such as validation of input data, schema validation failures, or validation constraints not being met. These errors indicate that the provided data or configuration does not adhere to the expected format or requirements specified by the workflow.

​
Expression Error

​
type
string
Expression error type
​
status
integer
default:"400"
Default status code
Description: Errors occurring during the evaluation of runtime expressions, such as invalid syntax or unsupported operations.

​
Authentication Error

​
type
string
Authentication error type
​
status
integer
default:"401"
Default status code
Description: Errors related to authentication failures.

​
Authorization Error

​
type
string
Authorization error type
​
status
integer
default:"403"
Default status code
Description: Errors related to unauthorized access attempts or insufficient permissions to perform certain actions within the workflow.

​
Timeout Error

​
type
string
Timeout error type
​
status
integer
default:"408"
Default status code
Description: Errors caused by timeouts during the execution of tasks or during interactions with external services.

​
Communication Error

​
type
string
Communication error type
​
status
integer
default:"500"
Default status code
Description: Errors encountered while communicating with external services, including network errors, service unavailable, or invalid responses.

​
Runtime Error

​
type
string
Runtime error type
​
status
integer
default:"500"
Default status code
Description: Errors occurring during the runtime execution of a workflow, including unexpected exceptions, errors related to resource allocation, or failures in handling workflow tasks. These errors typically occur during the actual execution of workflow components and may require runtime-specific handling and resolution strategies.
The default status code is provided for each error type. The status code that best describes the error should always be used.

​
Raising Errors

You can intentionally raise errors using the raise task: 
document:
  dsl: '1.0.3'
  namespace: test
  name: raise-example
  version: '0.1.0'
do:
  - processTicket:
      switch:
        - highPriority:
            when: .ticket.priority == "high"
            then: escalateToManager
        - mediumPriority:
            when: .ticket.priority == "medium"
            then: assignToSpecialist
        - lowPriority:
            when: .ticket.priority == "low"
            then: resolveTicket
        - default:
            then: raiseUndefinedPriorityError
  - raiseUndefinedPriorityError:
      raise:
        error:
          type: https://fake.com/errors/tickets/undefined-priority
          status: 400
          instance: /raiseUndefinedPriorityError
          title: Undefined Priority

​
Catching Errors

Use the try task with catch to handle errors gracefully: 
document:
  dsl: '1.0.3'
  namespace: test
  name: try-example
  version: '0.1.0'
do:
  - trySomething:
      try:
        - invalidHttpCall:
            call: http
            with:
              method: get
              endpoint: https://
      catch:
        errors:
          with:
            type: https://serverlessworkflow.io/spec/1.0.0/errors/communication
            status: 503
        as: error
        retry:
          delay:
            seconds: 3
          backoff:
            exponential: {}
          limit:
            attempt:
              count: 5

​
Error Filter Properties

​
with
object
required
A name/value mapping of the attributes filtered errors must define.
​
as
string
default:"error"
The name of the runtime expression variable to save the error as.
​
when
string
A runtime expression used to determine whether or not to catch the filtered error.
​
exceptWhen
string
A runtime expression used to determine whether or not to catch the filtered error.
​
retry
string | object
The retry policy to use, if any, when catching errors.If a string, must be the name of a retry policy defined in the workflow’s reusable components.
​
do
object
The definition of the task(s) to run when catching an error.

Build docs developers (and LLMs) love

Get started for freeTalk to us