3.3. Handle Failing Tasks

All applications can fail, often for reasons out of control of the user. A Task is no different, it can fail as well. Many non-trivial application will need to have a way to handle failing tasks – detecting the failure is the first and necessary step to do so, and RP makes that part easy: RP’s task state model defines that a failing task will immediately go into FAILED state, and that state information is available as task.state property.

The task also has the task.stderr property available for further inspection into causes of the failure – that will only be available though if the task did reach the EXECUTING state in the first place. In other cases, the application can inspect the task.as_dict()[‘execution_details’][‘log’] array of timed log messages, similar to the state_history array discussed before.

You can download the script 02_failing_tasks.py, which demonstrates inspection for failed tasks. It has the following diff to the previous example:


Instead of running an executable we are almost certain will succeed, we now and then insert an intentional faulty one whose specified executable file does not exist on the target system. Upon state inspection, we expect to find a FAILED state for those tasks, and a respective informative stderr output:

3.3.1. Running the Example

Running the example will result in an output similar to the one shown below:



You will see red glyphs during the result gathering phase, indicating that a failed task has been collected. The example output above also demonstrates an important feature: execution ordering of tasks is not preserved, that order is independent of the order of submission. Any task dependencies need to be resolved on application level!

3.3.2. What’s Next?

The next user guide section (Use Multiple Pilots) will return to the basic example (i.e., no failing tasks are expected), but will now submit those tasks to more than one concurrent pilots.