Неверная статистика пользователя в каталоге пользователей

[Moin]

Думаю, мне удалось воспроизвести это в Codespace, созданном на основе этой ветки.

Я попробовал, потому что сегодня заметил, что иногда цифры в каталоге пользователей неверны, и предположил, что это может быть связано с проблемой, когда пользователи не загружаются.

Пример неверных цифр, которые я заметил:

Это каталог пользователей в том виде, в котором он отображается при открытии. Период — неделя, сортировка по количеству полученных лайков. Теперь я изменю порядок на «Прочитанные посты»:

Затем изменю период на «сегодня»:

И то же самое (сегодня, сортировка по прочитанным постам) после перезагрузки:

Как видите, количество постов, прочитанных сегодня пользователем @lcor, изменилось после перезагрузки. До этого оно не вписывалось в отсортированный список.
На самом деле 214 — это количество постов, прочитанных за неделю:

Это был не единственный аккаунт, где цифры показывали недельный подсчёт вместо сегодняшнего при выполнении этих действий. Есть и другие пользователи, которые, кажется, находятся не на своих местах, хотя на самом деле отображаются недельные цифры.

Следующие пользователи в списке до/после перезагрузки

Как вы думаете, это та же проблема или сейчас случайно возникло две разные?

[Moin]

@Moin

Как вы думаете, это та же самая проблема или сейчас случайно возникло две проблемы?

Их было две. Другая уже исправлена.

Я всё ещё могу воспроизвести это с помощью шагов выше. Например, до перезагрузки статистика thoka отображается неверно:

А после перезагрузки — верно:

[zogstrip]

Я могу воспроизвести это здесь на meta. До обновления

После обновления

Числа действительно различаются, но что ещё важнее, мы всегда выполняем два запроса к конечной точке directory_items (один с расширением .json, другой без), но в одном из них указаны неверные параметры Однако воспроизвести это локально у меня не получается: у меня тоже два разных запроса, но они отправляются на разные конечные точки (groups/search.json против directory_items)

– EDIT: Включение компонента темы user card directory не меняет проблему/поведение.

[Moin]

Вы пробовали добавить больше пользователей в вашу локальную установку? Мне интересно, не нужно ли вам больше 50 пользователей, чтобы не все они загружались сразу.
Похоже, что пользователи с некорректными номерами — это те, кто не отображался при первой загрузке.

[zogstrip]

Я попытался кэшировать некоторые данные локально, чтобы не выполнять лишние запросы при каждой смене порядка сортировки или столбца.

PERF: cache requests when navigating user directory (#35371)

Но я не уверен, что это исправит проблему двойного запроса / состояния гонки, происходящую в продакшене, так как мне не удалось воспроизвести её локально

[zogstrip]

Хм, это не решило проблему с двойным запросом, и теперь я вижу ошибку JS: «loadMore» вызывается для undefined

[zogstrip]

В итоге это оказалась неприятная «гонка условий» между «сигнальным элементом» (sentinel), который мы используем для определения момента, когда нужно выполнить действие «загрузить ещё», и отрисовкой строк в каталоге пользователей

Проблема

При наличии не менее 50 пользователей страница /u (каталог пользователей) сразу при первой загрузке вызывала loadMore, ещё до того, как пользователь успевал прокрутить страницу вниз. Это приводило к автоматической загрузке нежелательной второй страницы результатов.

Коренная причина

Гонка условий по времени при первоначальной загрузке страницы:

1. Пользователь переходит на /u
2. controllers/users начинает загрузку данных (isLoading: true)
3. Шаблон отрисовывается с ConditionalLoadingSpinner, показывающим индикатор загрузки
4. Данные загружаются, isLoading становится false
5. Индикатор загрузки скрывается, DirectoryTable начинает отрисовку 50 пользователей
6. В DOM вставляется сигнальный элемент LoadMore
7. Создаётся IntersectionObserver и сразу начинает отслеживание
8. В этот момент таблица всё ещё вычисляет макет и расширяется до полной высоты
9. Сигнальный элемент на короткое время оказывается в области видимости (~292 пикселя от верха) до того, как таблица расширится
10. Наблюдатель обнаруживает пересечение → запускает loadMore
11. Таблица завершает расширение до полной высоты (~3689 пикселей)
12. Сигнальный элемент перемещается в правильное положение (~3959 пикселей, ниже области видимости)

Наблюдатель был «слишком нетерпелив» — он начал отслеживание до завершения разметки контента, зафиксировав сигнальный элемент в тот краткий момент, когда таблица ещё не достигла своей конечной высоты.

Исправление

Задержка создания наблюдателя до готовности контента:

Добавлен параметр @isLoading в LoadMore, который предотвращает создание IntersectionObserver, пока контент ещё загружается.

Как это работает теперь

Загрузка страницы → isLoading=true → Модификатор пропускает создание наблюдателя
             ↓
Загрузка данных → isLoading=false → Модификатор перезапускается, создаёт наблюдатель
             ↓
Таблица полностью расширена → Сигнальный элемент в правильном положении (ниже области видимости)
             ↓
Пользователь прокручивает вниз → Сигнальный элемент попадает в область видимости → loadMore срабатывает ✓

---

FIX: eager "load more" in users directory (#35439)