.png?sv=2022-11-02&spr=https&st=2024-11-14T22%3A32%3A17Z&se=2024-11-14T22%3A42%3A17Z&sr=c&sp=r&sig=%2Bo0iHE%2B0LPKyssCg5ynVZvGZmNeuaNys78rJRdj22PY%3D){kind=logo}
ErrorHandling
- 02 May 2024
-
DarkLight
-
PDF
ErrorHandling
- Updated on 02 May 2024
-
DarkLight
-
PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
ErrorHandling Task Purpose
The ErrorHandling manual task is available under Tools and performs error handling in a workflow. The task allows you to provide a severity level of fatal, warning or success as well as a status message. You may specify whether retry is allowed in the event of a fatal error, which is allowable by default. In the event of a fatal error, retry should revert back to a previous task in the workflow. Please see the section below under examples for more information.
Note:
ErrorHandlingis a manual task and must be assigned to a group in order to run.
Properties
| Incoming | Description |
|---|---|
severity string (required) |
The severity level must be one of the following values: fatal, warning or success. |
status string (required) |
The status is a string which should be indicative of the error state, and will be displayed to the user. This could be the returned status code from a REST call, or a custom message you supply. |
retry boolean |
Specifies whether retry is allowable in the event of a fatal error. Retry is true by default. |
| Outgoing | Description |
|---|---|
response |
The task will output a variable called response which will have one of the following values: success, failure, retry or error. |
Severity Level
The severity level variable may be supplied statically or dynamically, but must be one of the following values:
| Severity | Description |
|---|---|
fatal |
A fatal error is one which would prevent the workflow from reaching completion. The user will be prompted to either retry (if allowed) or abort the job. |
warning |
A warning will alert the user and allow them to proceed or abort the job. The warning level should be used for non-critical failures which will not hinder the completion of the job, but which should be made aware to the user. The warning level can also be used for control flow, allowing the user to continue down a given path with a warning or divert the job flow down another path if the user chooses to abort. |
success |
This can be used to confirm that a given task or series of tasks completed successfully. Note that the severity level can also be supplied dynamically, and this severity level can simply be used as a check before proceeding down a given path. |
Response
The ErrorHandling task will output a variable called response. This variable is especially useful when the severity level is provided dynamically, and the control flow of the job can be directed depending on the value. The response variable will be a string with one of the following values:
| Response | Description |
|---|---|
success |
This indicates either a successful status, or that the user has selected to proceed with warning. |
retry |
This indicates the user has selected to retry. In this case the output should revert back to an earlier task in the workflow. |
failure |
This indicates the user has chosen to abort. |
error |
This response is output when the severity level is supplied incorrectly, in the case that it is dynamically provided. This is merely a sanity check, and the response should never be an error. |
Examples
The following examples demonstrate various use cases for the ErrorHandling task.
Reverting to a Previous Task
Upon entering a state of fatal error, the user will be prompted to either retry (if allowed) or abort. It is a good idea to give the user the option to retry and revert to a prior state. As mentioned in the previous section, the response variable output from the ErrorHandling task will have the value of retry if the user has chosen to retry.
To perform this check, simply place an evaluation task after the error handling task.
From here, add a success edge to revert back to a prior task in the workflow, and then add a failure edge connecting to the end point of the workflow.
Directing Control Flow
There are scenarios where you may wish to direct the flow of control, such as performing cleanup tasks after an error has occurred. The ErrorHandling task can be used to give the user a warning, and then allow them to choose a path of execution.
The success path in this case would execute cleanup tasks, while the abort (failure) path would immediately end the job.
Verifying Successful Completion of a Task
The success severity level can be used to verify successful execution of a task or series of tasks.
This is useful in scenarios where the severity level and status are dynamically supplied.
Invalid Input
If invalid input is supplied to the ErrorHandling task, the task will output an error state with the following message.
This is a failsafe in the event that the severity level is provided dynamically and does not match one of the allowable severity level types.
Was this article helpful?
