Workflow States and Evaluation
Task states
During workflow execution, tasks usually get into several states which describe the lifecycle of the task. These states are:
-
WAITING: Task is waiting for the prerequisites to finish first.
-
IN_QUEUE: Task is scheduled for execution.
-
RUNNING: Task is being executed.
-
FINISHED_OK: Task execution successfully finished.
-
FINISHED_FAILURE: Task execution failed.
-
SKIPPED: Skipped because the condition on the link was not satisfied.
-
SKIPPED_FAILURE: Task was skipped because an ancestor task finished in the FINISHED_FAILURE state.
-
UNKNOWN: Unknown state - the process was terminated while the task was running, so it is not possible to determine the task state.
-
NOT_RUN: Task will not be run since there is no path from the initial nodes. This can happen when the workflow is resuming and the initial nodes are not detected automatically but provided from the outside. In that case, some tasks are not accessible and therefore receive this state.
Link states
Once all of the task prerequisites are processed, the workflow engine decides whether the task itself is processed or skipped. In order to decide, all of the task’s incoming links are evaluated to the states using the following logic:
-
Normal link:
-
Leading from a FINISHED_OK task and
-
Having a satisfied condition ⇒ ACCEPTED
-
Having an unsatisfied condition ⇒ REJECTED
-
-
Leading from a FINISHED_FAILURE task ⇒ SKIPPED_FAILURE
-
Leading from a SKIPPED task ⇒ SKIPPED
-
Leading from a SKIPPED_FAILURE task ⇒ SKIPPED_FAILURE
-
-
Error link
-
Leading from a FINISHED_OK task ⇒ REJECTED
-
Leading from a FINISHED_FAILURE task and
-
Having a satisfied condition ⇒ ACCEPTED
-
Having an unsatisfied condition ⇒ SKIPPED_FAILURE
-
-
Leading from a SKIPPED task ⇒ SKIPPED
-
Leading from a SKIPPED_FAILURE task ⇒ SKIPPED_FAILURE
-
In case multiple links lead to a task and:
-
All have ACCEPTED states, the task is processed.
-
All have SKIPPED, SKIPPED_FAILURE, or REJECTED states, the task is skipped with the SKIPPED_FAILURE state if at least one of the states is in the SKIPPED_FAILURE state or to the SKIPPED state otherwise.
Accept mode
If there are incoming links with different states, then the task Accept Mode property is considered. If the value of this property is:
-
ALL_VALID: The task is evaluated as:
-
SKIPPED
-
SKIPPED_FAILURE if there is at least one task with the SKIPPED_FAILURE state.
-
-
AT_LEAST_ONE: If at least one link is in the ACCEPTED state, the task is planned for processing and takes the processing result state.
| In both cases, the task does not run until all preceding tasks (and all other prerequisites) are finished. |
The purpose of the Accept Mode attribute is to set the leniency mode of the task:
-
strict mode (ALL_VALID) - Useful when the task requires all of its incoming links to be ACCEPTED (usually all prerequisite tasks finish successfully).
-
lenient mode (AT_LEAST_ONE) - Useful if it is necessary that the task can be triggered by different tasks. This is convenient for reporting errors: only one failed task is enough to trigger the error-reporting task for execution.
Workflow states
Similarly to tasks, the workflow as a whole has its own state. The workflow state depends on the states of all its tasks, so the workflow is always in one of the following states:
-
NOT_RUN: Workflow has not run yet.
-
RUNNING: Workflow is currently running.
-
FINISHED_OK: Workflow execution finished successfully.
-
FINISHED_FAILURE: Workflow execution failed.
-
STOP: Workflow was stopped by the user.
| FINISHED_FAILURE state is set only if some task fails and the Continue on Failure attribute is set to false (see Global Workflow Properties). Otherwise, the processing continues and the workflow ends with the FINISHED_OK state. |
Was this page useful?