Task skipping feature

During the workflow processing, situations may arise when the success or failure of the implementation depends on external factors.

Consider the situation: in the flow there is a task that requests any data from a third-party service while it is dead. Retries will not help in this situation, the task will go to the ERROR terminal state and the workflow will finish its work. Starting the workflow from the very beginning can be very expensive - it could have been several days before the fall. For such cases in the mistral there is a rerun mechanism - a certain decision maker determines whether circumstances have changed (whether third-party service has come to life), and if so, the workflow will continue its work from the fallen task.

In fact, the environment cannot always stabilize, and it can be very expensive to adapt the workflow to work with a new environment. Also it is not always possible to automatically assess the nature of the error that led to the fall. It can be something fatal, and maybe something insignificant, which in general does not affect the execution of the whole workflow. The decision maker can assess how important the results of the current task are and continue the execution of the workflow if not important.

It is proposed to add a new status "SKIPPED".

The transfer of the task to the SKIPPED state is made through a PUT request:
PUT / v2 / tasks
{
"id": <id>,
"state": "SKIPPED"
}

In the case of skipping a task, the work can be continued on an on-skip branch, in which case the task can fill in the previously prepared stub data:

wf:
  task1:
    action: some_custom_action
      publish:
        var1: <% task (). result.var1%>
        var2: <% task (). result.var2%>
        var3: <% task (). result.var3%>
      publish-on-skip:
        var1: "var1"
        var2: "var2"
        var3: "var3"
      on-success: task2
      on-skip: task2
  task2:
    action: std.noop