This ticket also depends on https://pagure.io/taskotron/libtaskotron/issue/178

This ticket had assigned some Differential requests:
D345

I'm not so sure this is needed - ABORTED and CRASHED are indications that there were problems with tasks which prevented them from being reported to resultsdb.

Yeah, but I think that current state is odd. [[ https://taskotron-stg.fedoraproject.org/taskmaster/builders/i386/builds/6664 | This build ]] was aborted. It hadn't failed, so it is green on buildbot, but it hadn't succeeded either, so it isn't in resultsdb. Because of that, it is impossible to find any aborted checks, but I thought that we will be interested in information about aborted tests.

+1 @jsedlak I'm not sure about CRASHED but if a check uses ABORTED (and to be honest, I do use it in Depcheck too), it seems like a reasonable addition - I do not want to have the whole depcheck "task" aborted because one update was incomplete. One specific result is ABORTED, the other results can be anything, and it does not make sense to abort the whole task. CRASHED though should IMHO be propagated to the task itself. I remember @kparal had some use-case, but I'cant think of any right now (for CRASHED).

We need to define what exactly ABORTED and CRASHED mean. In any case, it makes probably no sense to send this to Bodhi. But it might be a good idea to send it to ResultsDB. We are definitely interested in aborted or crashed tasks, and having them in ResultsDB will allow us to search for these problems easily. With ResultsDB we can easily filter for "aborted rpmlint checks for the past week" and investigate the issues.

ABORTED and CRASHED are indications that there were problems with tasks which prevented them from being reported to resultsdb.

We can certainly have this interpretation, but currently I don't consider these statuses to be exclusively related to resultsdb issues, but rather any issues - with the check script, with the environment, with the remote servers, etc.