Error Handling - need option to "fail" workflow

[k-jay-c]

Hi All,

Wanted to get another perspective on error handling with Serverless Workflow.

A State can have defined onErrors, with transition/end. If you have a transition, it can execute further states to recover or compensate for the error or terminate the execution.

I have 2 scenarios and feel that current error handling needs to be updated to correctly handle both scenarios.

Scenario 1:

• State "State1" defines an action that could return an error
• OnError matches the error, and defines a transition to another state "State2"
• Workflow continues executing "State2"
• The error defined in "State1" has been handled by executing "State2" and workflow is now proceeding.
• The error from first state should be discarded and workflow should complete successfully
• Example - State tries to download a file from FTP host. FTP host is down, but we've got a backup FTP host. OnError matches "connection refused" error, and transitions to another state that executes on backup host and succeeds.

Scenario 2:

• State "State1" defines an action that could return an error
• OnError matches the error, and defines a transition to another state "State2"
• Workflow continues to executing "State2"
• "State2" is just performing some clean up or email notification but workflow should still fail due to error in "State1"
• The error from "State1" should be returned with workflow failing
• Example - State tries to download a file from FTP host. FTP host is down, OnError matches "connection refused" error. OnError transitions to "Send Email to FTP Admin" state but then want to fail.

Currently, there is no way to define "Fail" workflow for Scenario 2.

Look forward to comments.

[cdavernas]

@k-jay-c Very nice discussion, which is exactly the rationale behind the error handling PR we have been working on. You can check it out here #673

[k-jay-c]

@cdavernas Thank you for the link, good to see the additions to error handling. However, from my brief read of the updated documentation, I don't think the above scenario is catered for. Could you confirm?

[cdavernas]

The scenario will be cared for, we will add an action used to throw an error explicitly ;)

[ricardozanini]

Hey, @k-jay-c, this is very similar to the other discussion I answered a few moments ago (#698). The DSL has been refactored to handle cases like this. Would you mind taking a look? https://github.com/serverlessworkflow/specification/blob/main/dsl.md#fault-tolerance