# User stats incorrect in user directory
**URL:** https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110
**Category:** Bug
**Tags:** user-directory
**Created:** [June 11, 2025, 9:55pm UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110 "2025-06-11T21:55:37Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [June 11, 2025, 9:55pm UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/1 "2025-06-11T21:55:37Z")
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?
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [October 9, 2025, 5:57am UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/2 "2025-10-09T05:57:24Z")
> [@Moin](#):
>
> Do you think this is the same issue or are there coincidentally 2 problems right now?
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:
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [October 14, 2025, 12:37pm UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/4 "2025-10-14T12:37:53Z")
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 🤔
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](https://meta.discourse.org/t/users-list-only-partial/368793/8) theme component doesn’t change the issue/behavior.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [October 14, 2025, 12:42pm UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/5 "2025-10-14T12:42:00Z")
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.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [October 14, 2025, 1:40pm UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/6 "2025-10-14T13:40:54Z")
I tried caching some data locally so we’re not doing unnecessary requests on every sorting order/column changes
>
>
> When changing the sorting column/order, we would always make a request
>
> \- to r…etrieve the list of groups ("/groups/search.json")
> \- to retrieve the list of columns ("/directory-columns.json")
>
> This adds some client-side cache to ensure we don't unecessarily requests those information over and over again.
>
> I'm also 50% hopeful that it might also fix the race condition described in https://meta.discourse.org/t/-/385110/4 - but I wasn't able to reproduce locally
But I’m not sure it’ll fix the double request / race condition happening in production as I wasn’t able to reproduce locally ☹
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [October 15, 2025, 8:14am UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/7 "2025-10-15T08:14:08Z")
Hmmm, this hasn’t fixed the double request issue and now I’m seeing a JS error with “loadMore” being called on `undefined` 🤔
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [October 16, 2025, 8:51am UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/8 "2025-10-16T08:51:26Z")
So this ended up being a nasty “race condition” between the “sentinel” we use to detect when we need to trigger the “load more” action and the rendering of the rows in the users directory 🤯
## The Issue
When there were **at least 50 users** , the `/u` (users directory) page was triggering `loadMore` immediately on first load, before the user could scroll down. This caused an unwanted second page of results to load automatically.
### Root Cause
**Timing race condition during initial page load:**
1. User navigates to `/u`
2. `controllers/users` starts loading data (`isLoading: true`)
3. Template renders with `ConditionalLoadingSpinner` showing spinner
4. Data arrives, `isLoading` becomes `false`
5. Spinner hides, `DirectoryTable` begins rendering 50 users
6. **LoadMore sentinel element is inserted into DOM**
7. **IntersectionObserver is created and starts watching immediately**
8. At this moment, the table is still calculating layout/expanding to full height
9. Sentinel is briefly visible in viewport (~292px from top) before table expands
10. Observer detects intersection → triggers `loadMore` ❌
11. Table finishes expanding to full height (~3689px)
12. Sentinel moves to correct position (~3959px, below viewport)
The observer was “too eager” - it started watching before the content finished its layout, catching the sentinel during the brief moment when the table hadn’t reached its final height yet.
## The Fix
**Delay observer creation until content is ready:**
Added an `@isLoading` parameter to `LoadMore` that prevents the `IntersectionObserver` from being created when content is still loading.
### How It Works Now
```plaintext
Page load → isLoading=true → Modifier skips observer creation
↓
Data loads → isLoading=false → Modifier re-runs, creates observer
↓
Table fully expanded → Sentinel at correct position (below viewport)
↓
User scrolls down → Sentinel enters viewport → loadMore triggers ✓
```
* * *
[https://github.com/discourse/discourse/pull/35439](https://github.com/discourse/discourse/pull/35439)
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [October 17, 2025, 6:00am UTC](https://meta.discourse.org/t/user-stats-incorrect-in-user-directory/385110/9 "2025-10-17T06:00:19Z")
This topic was automatically closed after 15 hours. New replies are no longer allowed.