Kill the max-count parameter

[Hexcles]

Currently the max-count parameter is a bit confusing (or sometimes buggy). The document says:

max-count : Maximum number of runs to get (for each browser).

And we have a default max-count of 1 (not documented).

Interaction with labels=experimental

/api/runs?labels=experimental only returns one run in total, not one run each browser. Other labels seem to work fine, so this is probably related to our special casing the "experimental" label (#311 ).

Interaction with sha=latest

When max-count is specified, sha=latest is ignored. e.g. /api/runs?max-count=5 gives five runs per browser, even though some of the runs are not at the latest SHA.

There might be some other edge cases.

[Hexcles]

I just confirmed that the first issue would be fixed by my #312 : https://remove-experimental-label-sp-dot-wptdashboard-staging.appspot.com/api/runs?labels=experimental

[Hexcles]

After some offline discussion, we finally realized that max-count was originally created for the /test-runs view when we didn't have the from parameter.

It turned out max-count wasn't ideal for that view, either (see #3 ), so we implemented from.

Basically, there's no use case for max-count any more and we can now safely remove this parameter altogether (regardless of whether we think its original semantics make sense or not).

cc @mdittmer

[lukebjerring]

I suspect @jugglinmike has a use-case for max-count, as he filed bug(s) about it recently?

[jugglinmike]

Thanks, @lukebjerring! (The issues Luke is referencing are gh-569 and gh-570.)

For my part, I'm trying to retrieve the "run" information for all the results uploaded in a given date range (specifically, quarter 3 of 2018). If the API returned all data following the date specified by from, then I could do this with a single request. Though in the absence of a corresponding until parameter (or similar), this could involve a lot of waste (perhaps a prohibitive amount) in some cases.

[jugglinmike]

Also note that currently, the system has limitations on the number of runs it can successfully serve. Without the ability to limit the number of results (e.g. via max-count), data for runs which occurred sufficiently far in the past cannot be retrieved:

$ curl https://wpt.fyi/api/runs?from=2018-07-01T00:00:00Z
API error 1 (datastore_v3: BAD_REQUEST): cannot get more than 1000 keys in a single call

I need this data to determine how dependable the results collection system was over the course of quarter 3.

@foolip discusses this use case in gh-588, and although he doesn't reference any errors, I believe they are the motivation for his request.

[foolip]

That's the error, yes. I reported it in #587 but that was a dupe.