Okay cool. So looks like ResultsDB has a default sort of submit_time descending, which means when we pick the first matching result in Greenwave we are already looking at the latest one.

The default sort order is not actually a documented part of ResultsDB API but I guess we could submit a PR to add it, since it probably something that Josef intended callers to be able to rely on.

So we can probably just take out this comment then, right?

# XXX need to handle multiple results (take the latest)

and maybe change it to a comment explaining that the first matching result is the latest.

# If we find multiple matching results, we always use the first one
# which will be the latest chronologically, because ResultsDB always
# returns results ordered by `submit_time` descending.

You could simplify this to just add a PASSED for 'dist.upgradepath' and then a FAILED for it below. Right now the test case has basically a hidden assumption that 'dist.upgradepath' is in TASKOTRON_RELEASE_CRITICAL_TASKS which might change in future.

Good idea.

So we can probably just take out this comment then, right?

XXX need to handle multiple results (take the latest)

and maybe change it to a comment explaining that the first matching result is the latest.

If we find multiple matching results, we always use the first one

which will be the latest chronologically, because ResultsDB always

returns results ordered by submit_time descending.

Indeed.

Rebased to address the comments.

Nice! :+1:

We should probably just send a PR to ResultsDB to add this (results are ordered by submit_time descending) into the API docs. And a test for it too. Since we are relying on that behaviour now.

Yeah, I'll do it.

Any link to that resultsdb change? (Any luck with phabricator?)

Also - is there anything blocking the merge of this PR now?

I've added a test in resultsdb for this and it is merged. However, I don't know where to update the API docs in resultsdb and they haven't told me yet.

https://pagure.io/taskotron/resultsdb/pull-request/83

There's nothing to stop us merging this one which I will go for it now.