Looks good to me, I'll merge this shortly. Thanks for the great work!

Josef, which Taskotron projects do we need to modify to make sure it still works well with the new ResultsDB?

@kparal Thing is, the content of the messages (or the logic behind spawning them) is not changing, only the "delivery framework" is, so the question is not "what should we change in order to work with new resultsdb", but "what should we switch from fedmsg to fedora_messaging"

I don't know that any of the bits in the taskotron stack consume the fedmessages ATM, other than trigger (and even that IMO does not consume the resultsdb messages). And that will need to be changed not because of the ResultsDB change, but to use the fedora_messaging instead of fedmsg.

Maybe openqa consumes resultsdb messages? But then again, the bit that receives the messages from the void needs to be changed, not the parts that use the content of them (AFAIK, @cverna could you confirm, please?)

@jskladan and @kparal that should not affect other systems, there is a bridge running between fedora-messaging and fedmsg that replicates the messages on the bus. So anything sent by fedora-messaging will still be available on the fedmsg bus.

We are planning to look at openqa you can see the status of the migration here (https://github.com/orgs/fedora-infra/projects/2). Note that this is focused on the application we need for rawhide gating.

FYI, this popped up as an error over in https://pagure.io/fedora-infrastructure/issue/7735