FWIW, the number of tasks we fetch from the API (which has performance implications), the number of cards we allow the user to page through, and the number we cap the result counter at, don't necessarily have to be the same. Detaching the first would take some engineering effort (making API continuation work), detaching the last would be trivial; so if we want to keep having 200 cards but show result counts up to, say, 1000, that would be easy to do.

In T242889#5807422, @Tgr wrote:

FWIW, the number of tasks we fetch from the API (which has performance implications), the number of cards we allow the user to page through, and the number we cap the result counter at, don't necessarily have to be the same. Detaching the first would take some engineering effort (making API continuation work), detaching the last would be trivial; so if we want to keep having 200 cards but show result counts up to, say, 1000, that would be easy to do.

This would be my preference, since the main purpose of the result count is to indicate that the user's filter selections are causing a change in the article results, so capping the counter number always at 200 will be extremely confusing. To be clear, I would prefer we do not set a cap on the counter, but only fetch the first 200 cards in the UI. In the case for example when the count is 350, if a user actually paginates to the 200th card, that's when we would load the next 150 cards.

To be clear, I would prefer we do not set a cap on the counter, but only fetch the first 200 cards in the UI. In the case for example when the count is 350, if a user actually paginates to the 200th card, that's when we would load the next 150 cards.

Sounds good to me. For consistency, I would support us showing the total number in all locations (task and topic dialogs, start editing dialog, and the in the pager (1 of ... 40,000).

Detaching the first would take some engineering effort (making API continuation work), detaching the last would be trivial; so if we want to keep having 200 cards but show result counts up to, say, 1000, that would be easy to do.

Another option is to cheat a little bit and show the full counter in the suggested edits module pager (e.g. 40,000 for arwiki) but only actually fetch 200 tasks as we currently do, on the assumption that few if any users are actually going to click the right arrow so many times. That would save us some engineering time. If we implemented a variant where it was actually important to fetch (in a paginated way) all the tasks, like if we had a UI that showed tasks in a grid display with many dozens of tasks per page, then we could do the extra engineering work to implement continuation between front-end and back-end in requests to the growthtasks API.

@MMiller_WMF do we want to move ahead with this?

Yeah, that's what I meant with "keep having 200 cards". We'd probably want to change the copy for the no more results card though (maybe even add a different variant for the "there are more results but we won't show them" case) because the current one seems confusing.

@RHo -- could you please update the task description with exactly the behavior that you think should be implemented?

De-prioritizing off the sprint board in favor of other tasks.