Global stats (all time) issue

[deksden]

Не синкается стата

локально так:

глобально по прежнему 200к сообщений

причем время, деньги - синкается. с ообщениями какая то легкая засада

[vakovalskii]

@deksden спасибо, что приложили оба скриншота — это сузило поиск. Копнул код, есть рабочая гипотеза.

Ключевая деталь: на лидерборд уходит stats.totals, а он в getLeaderboardStats() (src/data.js:6555) считается не по сессиям напрямую, а суммированием дневных бакетов:

const daily = getDailyStats(sessions);
for (const d of daily) { totalMessages += d.messages; ... }

То есть сообщение попадает в totals.messages только если сессия разложилась в дневной бакет, а для этого нужен разбираемый timestamp. Локальная вкладка статистики при этом считает иначе — по самим сессиям. Отсюда и расхождение: сессии, у которых таймстемпы не распарсились/пустые, тихо выпадают из синкаемого числа, но остаются в локальном.

Почему деньги и время «синкаются», а сообщения нет — тоже сходится: cost/hours берутся из того же цикла, но по ним разница в пару процентов незаметна, а на 200k сообщений выпадение целых периодов видно сразу.

Второй подозреваемый — кеш: LB_CACHE_TTL = 60s в памяти плюс дисковый кеш дневной статистики (DAILY_RESULT_CACHE_FILE) с ключом от _analyticsKey(sessions). Если ключ не меняется так, как ожидается, синк будет отдавать залежавшийся результат независимо от того, сколько раз нажать sync.

Чтобы не гадать, помогите одной диагностикой — сравните два числа на одной машине:

curl -s localhost:8420/api/stats           | head -c 400   # локальное
curl -s -X POST localhost:8420/api/leaderboard/sync | head -c 400   # что реально ушло

(порт подставьте свой). Плюс скажите, есть ли у вас очень старые сессии — например импортированные или Cursor/OpenCode, — я подозреваю именно их.

Беру в работу как баг. В 7.16.0 (уже собран) не попадёт, целюсь в следующий патч.

[vakovalskii]

Поправка к моему предыдущему комментарию — версия про выпадающие сессии оказалась неверной. Проверил на реальных данных (271 сессия), вот что получилось:

сессий без first_ts/last_ts:  0  (0.0%)
sum(s.user_messages):      1426
totals.messages (уходит):  4361

1. Сессии из дневных бакетов не выпадают. if (!s.first_ts || !s.last_ts) continue на моих данных не срабатывает ни разу, так что причина расхождения не в этом. Извиняюсь за ложный след.
2. Смеси метрик тоже нет — была моя вторая версия. _computeSessionDailyBreakdown считает только пользовательские промпты (isRealUserPrompt / entry.role !== 'user' → continue), как и fallback-ветка. Метрика определена одинаково везде, подпись «prompts» ей соответствует.
3. Разница 4361 против 1426 объяснилась банально: поле s.user_messages не заполнено у 232 из 271 сессий, а разбор detail-файлов даёт настоящий счёт промптов. То есть 4361 — это корректное число, а не завышенное.

Вывод: локальный расчёт totals.messages я воспроизвести как сломанный не смог — он выглядит правильным. А значит симптом «время и деньги синкаются, сообщения стоят на 200k» указывает не на этот репозиторий, а на серверную сторону лидерборда (хостится отдельно, кода в репе нет): похоже, поле сообщений там не перезаписывается при повторном синке.

Чтобы это подтвердить и передать дальше, всё ещё очень помогут два числа с вашей машины:

curl -s -X POST localhost:8420/api/leaderboard/sync | head -c 300   # что реально ушло
curl -s localhost:8420/api/leaderboard          | head -c 300   # что считается локально

Если в sync уходит правильное число, а на глобальной странице остаётся 200k — вопрос точно к серверной части, и я буду знать, что чинить не в клиенте.

Оставляю issue открытым.