What is an error?

Tray has a set of modes and tools that enable you to reliably deal with errors. This can be configured with the step properties and can be configured to:

1. Automatic

   • where failures will be retried automatically based on the error type

   • each error type has a max number of retry attempts and backoff logic associated with it

2. Manual Error Handling

   • which adds a success and failure path for the step based on whether it succeeds or not

   • does not execute automatic retries and backoff logic when legacy error handling is off

3. Continue

   • which ignores failures for that step and continues running the workflow to the next step

   • does not execute automatic retries and backoff logic when legacy error handling is off

For a step within a loop there are two further additional options

1. Break loop

   • which ignores failures for that step an continues by breaking out of the specified loop

   • does not execute automatic retries and backoff logic

2. Continue loop

   • ignores failures for that step an continues by skipping ahead to the next iteration of the specified loop

   • does not execute automatic retries and backoff logic

When dealing with errors it is important to understand there are essentially two types of errors to look out for:

• Tray errors

• 3rd party service errors

Tray errors

Copy

Tray errors tend to come from mis-configured workflow steps - e.g. you mis-configured a jsonpath to use $.steps.trigger.data.bod.email instead of $.steps.trigger.data.body.email

In this case the logs will return an error such as "message": "Reference: $.steps.trigger.data.bod.email in property: 'conditions[].value' did not resolve to any value."

Jsonpaths can be referenced by both 3rd party service connectors and Tray core and helper connectors.

These errors will always be picked up by alerting workflows which can help you make sure that no jsonpaths go 'out of date' with the source data they are pulling from (e.g. if a webhook payload suddenly changes from returning 'account_name' to just 'name')

It is important to note that depending on your workflow settings you may be using legacy manual error handling behaviours. Legacy manual error handling does not support tray errors. As such these errors cannot be handled manually at the connector level as can 3rd party service errors. Therefore make use of alerting workflows to monitor them. To enable or disable legacy manual error handling please see your workflow settings. More information is provided below.

3rd party errors​

Copy

3rd party errors can happen for a number of reasons

One possible reason is that the service may occasionally fail and return e.g. a 500 or 503 status.

Another possible reason is that you have attempted to retrieve a record which doesn't exist and the service returns a 404.

For example you may try and retrieve a non-existent card in Trello

(This screenshot shows an example of using the 'manual' error-handling option. Note that you can still use the default 'stop workflow (alerting)' option):

It is important to note, however, that 3rd party services will have their own policies on what is considered an error.

For example, when trying to retrieve a non-existent record in Salesforce, the Salesforce API will not return a 404 error.

Rather, it will return an empty array.

In this case we can use a boolean condition to check for an empty array and then take whatever action we feel necessary.

We could send an alert via email or to a Slack channel:

Or we could force an error as explained below:

Forcing errors​

Copy

In the example above you could force an error using the Terminate connector 'fail run' operation:

This would trigger a run of an alert-triggered workflow and pass on the message you have set:

Fallback values as an alternative to errors​

Copy

Note that, rather than allowing a workflow to error, you can also potentially make use of Fallback values to use e.g. empty strings, null values or default email addresses, phone numbers etc.

Legacy manual error handling

Copy

When using legacy manual error handling mode, only third party errors can be handled manually at the connector level. Alerting workflows should be used to monitor workflows using legacy manual error handling. To enable or disable legacy manual error handling please see the workflow settings.

To ensure compatibility, workflows by default will continue to use legacy error handling behaviours. This can be changed in your workflow settings. Please see below for a comparison of behaviours.