Skip to content

[bug]: 排行榜全部 Token 小于周/月,历史汇总疑似少算 #472

Closed

Description

@omsd512-W

Preflight checklist

  • 我搜索过已有 issue,发现了相关的 #263 和 #412,但在这些修复之后仍然遇到下面的现象。
  • 我使用的是最新版本 v0.88.9。

发生了什么?

我的 TokenTracker 账户是 omsd512@163.com,已开启云端同步。在排行榜中查看这个账号时,发现 全部 Token 数量小于 本月 和 本周 的数量。

我不确定这是历史汇总正在修复、不同页面统计范围不同,还是 total 快照存在其他问题,因此想请维护者帮忙核查。

2026-08-16(北京时间),排行榜接口对这个账号返回的数值如下:

周期 排行榜 Token 快照生成时间
本周 1,377,191,417 2026-08-16 05:18:24 +08:00
本月 2,707,415,992 2026-08-16 05:02:13 +08:00
全部 913,120,302 2026-08-16 05:02:19 +08:00

个人资料页的 total 视图(页面显示为近一年范围)约为 7,305,733,561 Token;其中本周和本月约为 1,436,892,713 和 2,745,556,245 Token。

三个排行榜快照都是当天生成的,所以看起来不只是浏览器缓存或页面没有刷新。

复现步骤

  1. 使用 TokenTracker 账户 omsd512@163.com 登录,并开启云端同步。
  2. 打开全球排行榜,找到当前登录账号对应的行。
  3. 分别查看本周、本月和全部。
  4. 打开该账号的个人资料页,对比 total 统计。
  5. 观察排行榜的全部数值小于本周和本月,而个人资料页包含更多历史用量。

期望行为

如果统计的是同一个账号,并且采用一致的统计口径,通常应该满足:

all-time total >= month total >= week total

希望排行榜的全部快照能够包含个人资料页中可见的历史用量。如果历史 rollup 仍在修复,是否可以暂时标记为更新中或延迟发布,而不是显示一个更新时间很新但明显小于本周/本月的全部数值?

这是回归吗?

不确定。

TokenTracker 版本

v0.88.9

Node.js 版本

v24.11.0

安装方式

Windows installer / zip

操作系统/版本

Windows 11

tokentracker doctor 输出(如适用)

暂未附上。这个现象看起来发生在云端排行榜历史快照,而不是本地解析器健康状态;如果需要,我可以再提供 doctor 输出。

其他信息

从仓库代码来看,全部周期使用每日历史 rollup 加实时增量,本周和本月则使用实时分组查询。可能相关的路径包括 v2 历史 rollup/repair 状态(tokentracker_leaderboard_rollup_daily_v2、tokentracker_leaderboard_rollup_meta_v2 和 leaderboard_rollup_daily_advance_v2)。

能否帮忙核查:历史数据延迟上传、设备集群变化,或每次七天的 repair 游标,是否可能导致 total rollup 仍不完整,但 total 快照仍然写入新的 generated_at?如果方便的话,重建这个账号的历史 rollup 和 total 快照应该可以帮助确认原因。

相关问题:

  • #263:全部快照因全历史刷新超时而冻结。
  • #412:全部排行榜的多设备历史用量少算,之后增加了机器集群感知的 rollup。
  • #467:另一个本地云端同步锁竞争问题;本 issue 的前提是数据已经能够在云端个人资料页中看到。

Activity

  1. linear commented on Aug 15, 2026

    @linear
  2. xiufengsun commented on Aug 16, 2026

    @xiufengsun
    Owner

    报告属实,已修复,你现在刷新排行榜应该能看到全部 ≈ 7.39B,不变式已恢复。

    根因:你判断的方向完全正确。全部周期 = 每日历史 rollup(closed-day 水位线)+ 水位线后的实时增量;本周/本月 = 纯实时分组查询。你的大部分历史用量属于「迟到上传」——数据到达云端时,对应日期的 rollup 已经生成过了,只能靠 repair 游标绕圈重建来补。问题在吞吐:total 刷新调度是每 6 小时一次,每次只推进 7 天,游标绕完全部历史一圈要 ~13 天。核查时你的游标在 2026-03-22,而你 3 月下旬之后的活跃天几乎全部缺失(hourly 有 173 个活跃天,rollup 里只有 92 天),所以 total 快照带着新鲜的 generated_at 却只有 0.9B。

    已做两件事:

    1. 手动重建了 2026-03-22 → 2026-08-15 的每日 rollup(重建函数逐天全量替换、幂等),你的 rollup 从 92 天 / 0.73B 补齐到 296 天 / 7.09B,并触发了 total 快照刷新——现在 total = 7,389,309,957 ≥ 本月 ≥ 本周。
    2. 治本:repair 推进原来搭在 6 小时一次的 total 刷新上,现已拆成独立的数据库级定时任务,每 10 分钟推进一次,全历史自愈周期从 ~13 天缩短到 10 小时以内。以后任何迟到的历史上传(包括多设备补传、修复版本发布后的补算)最迟半天内会反映到全部周期里。

    「rollup 未完成时暂缓更新 generated_at」的建议有道理,但在新的自愈周期下窗口已经缩到很小,暂不单独做标记。感谢这份把范围、快照时间和相关 issue 都列清楚的报告——直接指到了 v2 rollup 的正确位置,定位快了很多。

  3. omsd512-W commented on Aug 16, 2026

    @omsd512-W
    ContributorAuthor

    感谢修复和详细说明,刷新后已经正常了!👏

  4. locked as resolved and limited conversation to collaborators on Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions