Page MenuHomePhabricator

When too many results are counted for a check, work out what the best check(s) that could be run is.
Closed, DeclinedPublicFeature


Feature summary (what you would like to be able to do and where):
Checkusers when checking a large or busy range of IP addresses hit the "too many results" error. A guessing game of what filters will result in the most returned results then starts. This means that CUs on busy ranges may try all the different period options before finding a one that gives results. Each time they try to load the results it gives an extra CU log entry. With the potential implementation of filters to exclude users, ips and/or established users from the results it is likely going make choosing the combination that runs without the too many results error while maximising the returned results difficult leading to many checks. By providing the software's recommended "best check" for a range or IP, the CU can then go down to potentially two checks to get results that load.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
A CU loads a IP range for 'Get edits' which is larger or busy. The check has too many results, so it fails. The CU then has to guess a smaller and smaller period value until the check runs without error.
With this in place the CU performs the check which fails for too many results, but the software through some method recommends a check that would run without having too many results. The CU then uses these parameters, or a slightly modified version of the suggested parameters, to run next making the guessing game easier.

Benefits (why should this be implemented?):
This will reduce the number of checks in the CheckUserLog that return no results due to the query estimate being too large. This will also speed up the time it takes to run checks on busier IPs or larger ranges.

Event Timeline

This would be quite complicated. Essentially, if T311375 is implemented there is no need for this.

Between T311375 and T311363 I think this becomes nearly unnecessary and definitely not worth the effort. Decline?

I'm going to decline this in favour of T311375 and T311363.