The runs endpoint returns run records in a weird order. It's ordered first by state, with running > starting > (completed | failed | killed).
Within running and starting, the records are ordered by runid.
Within completed, failed, or killed, the records are ordered by start time.
I don't think this is intentional, as the row keys in the internal Table follow the following format:
This is inconsistent and confusing. It seems like the only reason to have a schema like this is if we wanted to efficiently scan for all run records in one of these quasi-states.
To me, it would make the most sense if everything was just ordered by start time, with everything having the same row prefix and everything including the inverted start time. This would also make each record correspond to a single row, instead of the four different possible rowkeys we have now, which requires four different lookups each time a run record is looked up.
This also makes it impossible to get the most recent run without examining all runs and sorting.