GarminHealthLab

Files

ericwyuan fd5e3363fd fix(garmin): 登录端点的 429 在封锁期内再试会延长封锁，唯独这一处要停手

实测记录：昨天为了验证令牌写回的修复，我发了一次 1 天同步，把 rate_limited_until
从 09-04T00:41 推到了 09-04T15:26——一次尝试，延长十五小时。

Garmin 的登录/换令牌端点和数据端点是两套规则：
- 数据端点的 429：本地冷却只是估算，过一会儿发个真实请求正是确认它有没有解除
  的唯一办法，没解除也不吃亏
- 登录端点的 429：窗口内每次尝试都把窗口往后推。这也是这个账号一直卡着出不来
  的原因——每次同步都去换一次令牌，每次都把封锁续上

所以：
- sync_status 加 rate_limit_source 列，记住 429 是哪个端点给的
- 只有 source=sso 且窗口未过时，才拒绝**刷新令牌**这一个动作

这个闸门刻意做得很窄，因为上一次的教训是「一刀切的闸门会让健康账号白白闲置」：
- 只拦刷新，不拦同步。库里的令牌只要还没过期，冷却期内照常同步
- 数据端点的 429 不参与判断——为了一次指标调用把账号锁一天，比问题本身更糟
- 用户可以推翻它：同步请求带 force 就先清掉冷却记录。那个截止时间是我们自己
  猜的 24 小时，不是佳明说的，所以必须能被推翻

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-04 06:13:52 +08:00

__init__.py

[阶段1.1-1.7] 实现完整的认证系统

2026-08-23 12:25:33 +08:00

analysis.py

feat(ai): 设置里加「AI 生成队列」，看得见后台在算什么

2026-09-01 16:02:05 +08:00

auth.py

feat(auth): 接入 auth-hub 统一登录，网页登录与 Garmin 同步彻底分离

2026-08-31 23:12:17 +08:00

garmin.py

fix(garmin): 登录端点的 429 在封锁期内再试会延长封锁，唯独这一处要停手