A task can run rhts-abort -t recipe, which should make all unfinished tasks in the recipe Aborted (and thus, the entire recipe will be Aborted).

However in some circumstances the aborting task will actually end up Completed not Aborted. The sequence of calls looks like this from the server POV:

DEBUG Time: 0:00:00.011789 taskactions.task_info ('T:130582',)
DEBUG Time: 0:00:00.029620 recipes.tasks.start ('130582', 0)
DEBUG Time: 0:00:00.010392 recipes.tasks.extend ('130582', 1200)
DEBUG Time: 0:00:00.009883 recipes.tasks.extend ('130582', 12600)
DEBUG Time: 0:00:00.010664 recipes.tasks.extend ('130582', 12600)
DEBUG Time: 0:00:00.026424 recipes.stop ('13117', 'abort', 'Recipe aborted by task 130582'
DEBUG Time: 0:00:00.008990 recipes.tasks.result ('130582', 'pass_', '/distribution/command', '0',
                           ^--- this one fails because the task is already finished
DEBUG Time: 0:00:00.009539 recipes.tasks.extend ('130582', 14400)
DEBUG Time: 0:00:00.019204 recipes.tasks.stop ('130582', 'stop', 'OK')

The problem is that Beaker is allowing the tasks to transition from Aborted -> Completed. But changing status once a task has finished is supposed to be illegal. So the second call to recipe.tasks.stop ('stop') should fail.

In the cases where the recipe is aborted by the external watchdog or installation failure, we don't see this problem, because there is no harness still running trying to complete tasks. This is only an issue when rhts-abort -t recipe is used, and then the task proceeds to exit normally and the harness wants to complete it.

A workaround would be to put some large sleep after invoking rhts-abort.