Jump to: navigation, search

Difference between revisions of "TaskFlow/States of Task and Flow"

(Flow States)
(Flow States)
Line 1: Line 1:
 
== Flow States ==
 
== Flow States ==
  
[[File:Tf flow state diagram.png|150px|thumb|Flow state diagram]]
+
[[File:Tf flow state diagram.png|200px|thumb|Flow state diagram]]
 
   
 
   
A <code>Flow</code> starts its life in the'''PENDING''' state. Then, when it is run, it transitions to the '''RUNNING''' state, and stays in that state until it has finished; once '''all''' tasks have finished successfully the flow transitions to the '''SUCCESS''' state or,  in case of failure, to the '''FAILURE''' state.
+
A <code>Flow</code> starts its life in the '''PENDING''' state. Then, when it is run, it transitions to the '''RUNNING''' state, and stays in that state until it has finished; once '''all''' tasks have finished successfully the flow transitions to the '''SUCCESS''' state or,  in case of failure, to the '''FAILURE''' state.
  
 
From the '''FAILURE''' state the flow begins the process of reversion; when this happens, the flow first transitions to the '''REVERTING''' state, then reversion happens, then the flow transitions to the '''REVERTED''' state, if reversion completed succesfully, or to the '''FAILURE''' state if some tasks failed to revert.
 
From the '''FAILURE''' state the flow begins the process of reversion; when this happens, the flow first transitions to the '''REVERTING''' state, then reversion happens, then the flow transitions to the '''REVERTED''' state, if reversion completed succesfully, or to the '''FAILURE''' state if some tasks failed to revert.

Revision as of 07:20, 11 October 2013

Flow States

Flow state diagram

A Flow starts its life in the PENDING state. Then, when it is run, it transitions to the RUNNING state, and stays in that state until it has finished; once all tasks have finished successfully the flow transitions to the SUCCESS state or, in case of failure, to the FAILURE state.

From the FAILURE state the flow begins the process of reversion; when this happens, the flow first transitions to the REVERTING state, then reversion happens, then the flow transitions to the REVERTED state, if reversion completed succesfully, or to the FAILURE state if some tasks failed to revert.

In the RUNNING state and the REVERTING state the flow can be suspended. When this happens, flow transitions to SUSPENDING state immediately. In that state the engine running the flow waits for running tasks to finish. Then, when no tasks are running and all results received so far are saved, the flow leaves the SUSPENDING state. It may go to the SUCCESS state if all tasks were in fact run, or to the "REVERTED" state if the flow was reverting and all tasks were reverted while engine was waiting, or to the FAILURE state if tasks were run or reverted and some of them failed, but in most common case flow transitions to the SUSPENDED state after the SUSPENDING state. From the SUSPENDED state the flow can resume running (aka, transition back to the RUNNING state) or perform reversion (aka, transition to the REVERTING state).

When is interrupted 'in a hard way' (e.g. server crashes), it can be loaded from storage in any state. If the state is not PENDING (flow was never run) or SUCCESS, FAILURE or REVERTED (in which case flow is already finished), the flow gets to the RESUMING state for the short time period when it is loaded from database (this transition is not shown on the diagram). When the flow is finally loaded from database, it goes to into the SUSPENDED state.

From the SUCCESS, FAILURE or REVERTED states the flow can be run again (and thus it goes to RUNNING' state). One of the possible use cases for this transition is to allow for alteration of a flow or flow details associated with that flow after the flow was finished, and client code wants to ensure that each task from this new updated flow has its chance to run.

The current code also contains strong checks during each flow state transition using the model described above and raises an InvalidStateException if invalid transition is attempted. This usually means there is some kind of bug in engine or some type of misuse/state violation is occuring, and should be reported as such.


Task States

Task state diagram

When task just added to the flow, it is in PENDING state, which means it can be executed or waits for all of task it depends on to complete. Then, when task is executed, it transitions to RUNNING state, and stays in it until its execute() method returns. When task is finished, it transitions to SUCCESS state if it was finished successfully, or to FAILURE state if not.

When flow is reverted, all tasks in PENDING state are left as is; tasks from all the other states transition to REVERTING state, and their revert() method is called. When that method returns, task transitions to REVERTED state, and then to PENDING.

Transition from RUNNING to REVERTING state happens when task was interrupted while running, and then revert occurs. This may take place e.g. when daemon is killed while running the task.

Transition from REVERTED to PENDING state happens immediately. The main purpose of REVERTED state is notifications.


Vendor-Specific States

Tasks that are running vendor-specific code can have some other states to implement some custom logic/notifications and change task's metadata. However transitions between such vendor-specific states are enclosed in one of common states which are shown in the diagram.

For example task's state transitions can be:

PENDING --> RUNNING --> (any vendor specific states/transitions) --> RUNNING --> SUCCESS

Note: there should likely be a way to make (any vendor specific states/transitions) configurable in that the vendor specific states/transitions may not need to be persisted to permanent storage. Perhaps a task property maybe appropriate?