User stats incorrect in user directory

I think I was able to reproduce it in a Codespace built based on that branch.

I tried because today I noticed that sometimes the numbers in the user directory are wrong and I thought that maybe it’s because of the issue that users are not loaded.

Example of the wrong numbers I noticed:


This is the user directory as it looks when you open it. Timespan weekly, ordered by likes received. Now I change the order to Posts read:

Then I change the timespan to today:

And the same (today, ordered by posts read) after a reload

As you can see, the number of posts @lcor read today changed after the reload. Before, it didn’t fit into the ordered list.
Actually, the 214 are the posts read this week:


This was not the only account where the numbers showed the weekly count instead of today’s when I performed these steps. There are more users that look like they aren’t at the right place, where actually the weekly numbers are shown.

Next users in the list before/after reload

Do you think this is the same issue or are there coincidentally 2 problems right now?

4 likes

There were 2. The other one is fixed.

I can still reproduce this with the steps above. For example, thoka’s stats are wrong before the reload:

And correct after the reload:

I’m able to reproduce here on meta

Before refresh

After refresh

The numbers are indeed different but what’s more important is that we’re always doing two requests to the directory_items endpoint (one with, the other without the .json extension) but one of them has incorrect parameters :thinking:

I can’t however reproduce locally, I have two different requests, but they’re on different endpoints (groups/search.json vs directory_items)

EDIT: enabling the user card directory theme component doesn’t change the issue/behavior.

Did you try adding more users to your local install? I wonder if you need more than 50 users, so not all of them are loaded at once.
I think the users who show wrong numbers were the ones not visible on first loading.

I tried caching some data locally so we’re not doing unnecessary requests on every sorting order/column changes

But I’m not sure it’ll fix the double request / race condition happening in production as I wasn’t able to reproduce locally :frowning:

2 likes

Hmmm, this hasn’t fixed the double request issue and now I’m seeing a JS error with “loadMore” being called on undefined :thinking: