Rerun task/job

[mthuurne]

If a task execution hits an occasional error, it would be useful to rerun the task in the hope it will complete the next time. Such occasional errors could be caused by problems such as loose cables, power failure or software crashes.

For example, when recovering from the situation where a Task Runner was aborted, it would be useful to automatically add another run of the same task. Then another TR can execute it, or the same TR after it has recovered (for example when its host comes back up after a power failure).

A possible UI feature: add a rerun button next to each task/job in the report view. However, it is not clear whether this is desirable, since finished jobs could become "in progress" again, which may be confusing to the user. Maybe rerunning aborted tasks or tasks with errors should be allowed, but rerunning successful tasks should not? An alternative would be to implement user-requested reruns by creating a new job which uses the same settings (locators, parameters) as the original job.

When multiple runs of the same task are possible, it would be possible to implement the current "execute N times" feature by creating N runs within a single job, instead of creating N jobs. This would make it easier to get an overview of the results.

In any case a re-run feature should only add runs to the database, it should never replace existing runs, since we do want the execution history to represent what actually happened.

[mthuurne]

Note that if a wrapper or test tool is broken, a task that is listed as successful ("ok") might actually not be. Or perhaps it ran correctly but the wrapper didn't provide the right reports or products in the results. So making a distinction on result code as I suggested in the initial post is not a good idea.

There are a lot of complications when jobs that were in a final state can be taken out of that state by a rerun. Both the database schema and the API are more complex if there can be more than one run of a task inside a job. And an "inline" rerun can lead to subtle problems, since it would be using frozen task definitions but the latest versions of the wrappers. So instead of touching the existing job, I think it's better to only allow reruns by creating a (partial) clone of an existing job.

If we replace the current history-focused Home page with a dashboard (#14), having unrepresentative jobs in the history is much less of an issue. So the goal of a rerun is then simply to be able to get another execution queued without having to create an ad-hoc job from scratch.