Page MenuHomePhabricator

SE counter and post-edit dialog counter display wrong number of fetched articles when user navigates through them
Closed, DeclinedPublic

Description

The issue was reported in two comments on T308887 - comment 1 and comment 2 .

Steps to reproduce the issue:

  1. On testwiki wmf.28 go to Special:Homepage
  2. Select Technology + Add link between articles (structured task) + Update articles. The counter states 1 of 59
  3. Start flipping trough the articles - after 37, the counter to display - 38 of 50.

The animated gif shows the count starting from 33 of 59 .

counter3_40_50.gif (731×1 px, 378 KB)

Note: The issue is not specific to the filter selection described in the steps above. Any number of tasks >21 will display the issue. The issue was present when the number of fetched tasks was 38 and 45.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Etonkovidova renamed this task from SE counter and post-edit dialog counter display wrong number of fetched articles to SE counter and post-edit dialog counter display wrong number of fetched articles when user navigates through them .Sep 12 2022, 9:03 PM

@Etonkovidova we just merged two patches related to counter discrepancies (rEGRE2b98a236a8e5: GrowthTasksApi: avoid using continue and increase look ahead, rEGREf0365e564338: Newcomer tasks: dont emit update event until count is set) so I would suggest waiting until those are in group0 before looking at any counter issues.

That said, @Sgs and I were discussing this task earlier today, and we are not sure if there is really an error here. We cannot in advance know the total number of valid tasks. Some get filtered out as we page through results, so the total number can drop. @Sgs and @RHo talked about a design implementation that would provide a visual cue to the user that the total count has changed, but I am not sure if there is a task for that already.

Moving this to Growth design team workboard, to think about how we can communicate the reduction in the total as we page through results.

Moving this to Growth design team workboard, to think about how we can communicate the reduction in the total as we page through results.

@RHo already designed an experience for this issue, see T309614: Newcomer tasks: add intermediate loading state. Doing a quick review, I think it is actionable already.

Moving this to Growth design team workboard, to think about how we can communicate the reduction in the total as we page through results.

@RHo already designed an experience for this issue, see T309614: Newcomer tasks: add intermediate loading state. Doing a quick review, I think it is actionable already.

Right, thanks for finding that one! In that case, I would propose that we decline this task and move T309614 into some upcoming sprint. What do you think, @KStoller-WMF ?

That makes sense to me.

I added T309614 to the current sprint, which should cover a solution to this problem, so I'll decline this task.