API: Results ordering limits utility of from parameter

[jugglinmike]

When the data returned by /api/runs is truncated by max-count, it prioritizes more recent data. Because the server sets hard limits on the number of results it will return, this behavior means older results can't be retrieved:

$ curl 'https://wpt.fyi/api/runs?from=2018-07-01T00:00:00-04:00&max-count=5' | python -c 'import json, sys; print "\n".join([x["created_at"] for x in json.loads(sys.stdin.read())])'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13300  100 13300    0     0  25829      0 --:--:-- --:--:-- --:--:-- 25875
2018-09-19T19:15:43.418629Z
2018-09-19T18:37:49.814379Z
2018-09-19T09:14:49.484807Z
2018-09-19T05:19:12.087341Z
2018-09-19T06:47:34.644255Z
2018-09-19T06:08:01.782948Z
2018-09-18T06:24:24.505601Z
2018-09-17T03:15:25.279373Z
2018-09-16T03:49:12.577577Z
2018-09-15T06:49:07.095779Z
2018-09-19T17:34:12.912039Z
2018-09-19T03:21:12.631356Z
2018-09-18T22:13:45.732254Z
2018-09-18T14:34:40.634335Z
2018-09-18T12:41:28.159062Z
2018-09-19T09:34:15.331304Z
2018-09-18T09:53:21.336091Z
2018-09-17T04:56:38.038864Z
2018-09-16T21:49:29.386713Z
2018-09-16T09:32:36.593057Z

It does look like the parameter is correctly filtering results. That's not evident in the above example, but it can be observed by setting the parameter to a recent date:

curl 'https://wpt.fyi/api/runs?from=2018-09-18T00:00:00-04:00&max-count=5' | python -c 'import json, sys; print "\n".join([x["created_at"] for x in json.loads(sys.stdin.read())])'                                                                                                                                                                                                            
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  8103  100  8103    0     0  15764      0 --:--:-- --:--:-- --:--:-- 15764
2018-09-19T19:15:43.418629Z
2018-09-19T18:37:49.814379Z
2018-09-19T09:14:49.484807Z
2018-09-19T05:19:12.087341Z
2018-09-19T06:47:34.644255Z
2018-09-19T06:08:01.782948Z
2018-09-19T17:34:12.912039Z
2018-09-19T03:21:12.631356Z
2018-09-18T22:13:45.732254Z
2018-09-18T14:34:40.634335Z
2018-09-18T12:41:28.159062Z
2018-09-19T09:34:15.331304Z

[lukebjerring]

I don't actually think this is a bug; are you requesting that we reverse the ordering? If so, I'd change this to "Support ordering /api/runs by time_start ascending" and propose we support ?order=asc or similar.

[lukebjerring]

P.S. the alternative here, if you're paginating, is to use the to param.

[jugglinmike]

Ah, I see. The "newest first" sort order was only a problem in the absence of a to parameter. max-count may still be a little hard to use without control over order, but for my purposes, combining from with to should suffice. Thanks!