Change 543689 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/core@master] Move countRevisionsBetween from Title to RevisionLookup

https://gerrit.wikimedia.org/r/543689

Change 543718 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/core@master] REST: Implement /revision/{from}/intermediatecount/{to} endpoint.

https://gerrit.wikimedia.org/r/543718

Back in 2014 the following patch has added a limit to the Title::countRevisionsBetween method that we intend to use in the implementation here with a rationale that a query was causing DB timeouts. The query we're going to use is the same, thus I think it has the potential to keep timing out.

@eprodromou should we try to implement it without the limit (I don't think we should expect different result trying the same thing), or should we be prepared to specify that if the number of revisions between is more the 1000 (1000 is used by web UI, quite an arbitrary number), we will return something special? If so - what?

Change 543689 merged by jenkins-bot:
[mediawiki/core@master] Move countRevisionsBetween from Title to RevisionStore

https://gerrit.wikimedia.org/r/543689

In T235666#5582750, @Pchelolo wrote:

Back in 2014 the following patch has added a limit to the Title::countRevisionsBetween method that we intend to use in the implementation here with a rationale that a query was causing DB timeouts. The query we're going to use is the same, thus I think it has the potential to keep timing out.

We have SSDs now and faster machines, but that just raises the threshold for "too many" rather than eliminating it. I think a limit would still be a good thing.

we will return something special? If so - what?

If we don't care that it would mean 'count' is sometimes an integer and sometimes a string, I'd do something like "1000+" or ">1000". But we probably do care, in which case I don't have a good idea. We could make it an error case (but what code? 403?), or return a response without a 'count' at all, or just document that "1001" means "some number more than 1000".

In T235666#5582750, @Pchelolo wrote:

@eprodromou should we try to implement it without the limit (I don't think we should expect different result trying the same thing), or should we be prepared to specify that if the number of revisions between is more the 1000 (1000 is used by web UI, quite an arbitrary number), we will return something special? If so - what?

A 500 error should be fine. I think it's pretty hard to make this happen with most UIs.

Change 545923 had a related patch set uploaded (by Will Doran; owner: Ppchelko):
[mediawiki/core@master] REST: Implement from and to for editors count handler.

https://gerrit.wikimedia.org/r/545923

Not sure if I should review https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/543718/

Are we adding a max? If so, are we doing the 500 error, or the "limit" in the response per https://phabricator.wikimedia.org/T235572#5621346 ?

yeah, @BPirkle I have decided to pause here too in anticipation of the decision what to do. I think we should apply a limit to all the count types and the limit should be the same and we should follow your design there.

@Pchelolo I don't think we can add a limit to all the *count endpoints before the train goes out on Tuesday. If you think we can, let's do it, and I'll modify the use cases. If not, let's capture it as separate tasks that we'll do this sprint or later.

In T235666#5625143, @eprodromou wrote:

@Pchelolo I don't think we can add a limit to all the *count endpoints before the train goes out on Tuesday. If you think we can, let's do it, and I'll modify the use cases. If not, let's capture it as separate tasks that we'll do this sprint or later.

We can add it to the rest of endpoints separately. What I care about is the eventual consistency.

Change 547682 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/core@master] REST History Counts: Limit the number of edits to count

https://gerrit.wikimedia.org/r/547682

In T235666#5625162, @Pchelolo wrote:

In T235666#5625143, @eprodromou wrote:

@Pchelolo I don't think we can add a limit to all the *count endpoints before the train goes out on Tuesday. If you think we can, let's do it, and I'll modify the use cases. If not, let's capture it as separate tasks that we'll do this sprint or later.

We can add it to the rest of endpoints separately. What I care about is the eventual consistency.

I think that's a great point. I'm going to add this as separate tasks for each of the "count" endpoints, so we can schedule them for later tasks.

for each of the "count" endpoints

PLEASE DON'T! :) Please make one task, this will be one code change, treating each of the counts separately will create the same mess as we've had for deprecation tickets. Too granular.

OK! I added a user story to the extended history epic, T237115.

Change 543718 merged by jenkins-bot:
[mediawiki/core@master] REST: Add 'from' and 'to' parameters to historycount endpoint.

https://gerrit.wikimedia.org/r/543718

Change 545923 merged by jenkins-bot:
[mediawiki/core@master] REST: Implement from and to for editors count handler.

https://gerrit.wikimedia.org/r/545923

Change 552321 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[mediawiki/tools/api-testing@master] REST: Add tests for from/to parameters and cache challenges

https://gerrit.wikimedia.org/r/552321

Change 552321 merged by jenkins-bot:
[mediawiki/tools/api-testing@master] REST: Add tests for from/to parameters and cache challenges

https://gerrit.wikimedia.org/r/552321