### Preflight checklist - [x] 我搜索过[已有 issue](https://github.com/xiufengsun/TokenTracker/issues),发现了相关的 [#263](https://github.com/xiufengsun/TokenTracker/issues/263) 和 [#412](https://github.com/xiufengsun/TokenTracker/issues/412),但在这些修复之后仍然遇到下面的现象。 - [x] 我使用的是最新版本 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. 观察排行榜的全部数值小于本周和本月,而个人资料页包含更多历史用量。 ### 期望行为 如果统计的是同一个账号,并且采用一致的统计口径,通常应该满足: ```text 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](https://github.com/xiufengsun/TokenTracker/issues/263):全部快照因全历史刷新超时而冻结。 - [#412](https://github.com/xiufengsun/TokenTracker/issues/412):全部排行榜的多设备历史用量少算,之后增加了机器集群感知的 rollup。 - [#467](https://github.com/xiufengsun/TokenTracker/pull/467):另一个本地云端同步锁竞争问题;本 issue 的前提是数据已经能够在云端个人资料页中看到。
Activity
linear commentedon Aug 15, 2026
001-254
xiufengsun commentedon Aug 16, 2026
报告属实,已修复,你现在刷新排行榜应该能看到全部 ≈ 7.39B,不变式已恢复。
根因:你判断的方向完全正确。全部周期 = 每日历史 rollup(closed-day 水位线)+ 水位线后的实时增量;本周/本月 = 纯实时分组查询。你的大部分历史用量属于「迟到上传」——数据到达云端时,对应日期的 rollup 已经生成过了,只能靠 repair 游标绕圈重建来补。问题在吞吐:total 刷新调度是每 6 小时一次,每次只推进 7 天,游标绕完全部历史一圈要 ~13 天。核查时你的游标在 2026-03-22,而你 3 月下旬之后的活跃天几乎全部缺失(hourly 有 173 个活跃天,rollup 里只有 92 天),所以 total 快照带着新鲜的 generated_at 却只有 0.9B。
已做两件事:
「rollup 未完成时暂缓更新 generated_at」的建议有道理,但在新的自愈周期下窗口已经缩到很小,暂不单独做标记。感谢这份把范围、快照时间和相关 issue 都列清楚的报告——直接指到了 v2 rollup 的正确位置,定位快了很多。
omsd512-W commentedon Aug 16, 2026
感谢修复和详细说明,刷新后已经正常了!👏