This might help to reduce the set of result IDs we are looking up in some cases, but it doesn't seem like it will fix the problem for real. For example we could easily have 100 "latest" results for 100 different test cases. Replace 100 with whatever number is large enough to exceed the URL query string length limit.

I guess this is the same issue we had (or anticipated having) in Greenwave, which is that jamming these arbitrarily long parameters into the query string will eventually hit the size limit.

Maybe we need to implement a POST version of the endpoint which we can call instead, to avoid the length limit?

So "only get the latest test results" is not an issue, it's a (potential) solution. :-) The actual issue here is that the call to WaiverDB can fail if there is a large number of results which causes the query string to exceed the length limit, resulting in WaiverDB returning a 4xx response.

Will update the issue title to reflect that...

Cool, thanks for updating the issue tile to make it clear. We may not need to bother fixing this if we are going to introduce a cache mechanism as described in #77

After seeing #84, it turns out we may still need to implement a POST version of the endpoint in waiverdb to avoid the length limit. It was my bad that I did not fully understand the whole idea described in #77.

See waiverdb#83

See PR#88

Almost there! :)