ericwyuan
|
1c80b16325
|
fix(garmin): 重新绑定走的是同一个被封的登录接口，也得拦住
用户问：限流了，重新输账号密码验证码换个新令牌行不行。
不行，而且是最糟的一种试法。`garth.login()` 和 `refresh_oauth2()` 打的是
同一个 SSO 端点，流程还更重；限流按**账号**计（不是按 IP、按 UA），换设备
换网络都绕不开；而窗口内每次尝试都会把窗口往后推。
而这正是被卡住时第一个会去试的操作，代码里却只有 `_connect` 的刷新有闸门，
重新绑定那条路照发不误。
- start_login 在 sso 冷却窗口内直接拒绝，不建会话行、不碰网络
- 错误信息说清三件事：为什么现在不试、什么时候恢复、换设备没用
- 路由返 429（请求本身没毛病，是该晚点再来）并带 retryAfterSeconds
- 数据端点的 429 不参与拦截，force 可以推翻
前端补上 UI：报错文案早先承诺了「同步页选择强制重试」，但那个按钮不存在。
现在只在被冷却拒绝之后才出现，样式刻意做得不像第二个「开始同步」——它是给
估算失准时的出口，不是随手可点的第二选择。
顺带修一个正要被我引入的 bug：`onClick={syncHistory}` 会把 MouseEvent 当成
force 传进去，等于每次点开始同步都跳过冷却。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-04 06:20:05 +08:00 |
|
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 |
|
ericwyuan
|
7e51223eb9
|
fix(rate-limit): _is_rate_limited 识别 RetryError 的 429 形态，登录 429 真正触发自动退避
生产实测：登录时 garth 把 429 折进 RetryError（'too many 429 error responses'），无 status_code、无 'rate limit' 字样，旧检测漏判 → 走 else 分支存原始报错、不调 _note_rate_limit，冷却永远不落库，用户可反复撞 Garmin。\n\n- garmin.py: _is_rate_limited 沿 __cause__ 链找 429 响应，并接受文本中的 '429' 标记。\n- garmin_auth.py: 退避文案 6h 改为 24h。\n- 生产：已补挂 24h 冷却（2026-08-30 10:00 北京），RetryError 形状验证识别为 429。
|
2026-08-29 10:00:30 +08:00 |
|
ericwyuan
|
ae126f90d4
|
fix(rate-limit): 退避延长至 6h 且登录路径同样遵守，打破 Garmin 限流死循环
根因：迁移后自动同步+旧 oauth2 刷新轰炸把 Garmin 账号撞进限流黑洞；退避原仅 60min 且登录路径完全不检查，导致每小时退避到期又撞一次 429、登录也直接连 Garmin 被 429，窗口永远退不出。
- garmin.py: RATE_LIMIT_BACKOFF 60min->6h；_note_rate_limit 改为固定 now+6h（不再短延期）。
- garmin_auth.py: _run_login 入口先查 rate_limited_until 拦截（不撞 Garmin），遇 429 也调 _note_rate_limit 延长退避。
- 已在生产把 sync_status.rate_limited_until 设到 now+6h，强制 Garmin 安静以让窗口真正关闭。
|
2026-08-28 17:18:37 +08:00 |
|
ericwyuan
|
bb774c332b
|
[阶段5.2] 两步验证改到网页端完成，手机上即可绑定 Garmin
背景：命令行方案要求用户在电脑前开交互式终端，实际不可行。
改为在网页里完成 MFA，手机也能操作。
难点：garth 索取验证码走的是 *阻塞回调*，0.4.46 没有
"发起登录 -> 返回句柄 -> 稍后续接" 的接口，登录必须一直挂着。
而 gunicorn 跑多个 worker，验证码请求不一定落到挂着登录的那个 worker。
方案：登录跑在后台线程里，停在 prompt_mfa 内轮询数据库；
浏览器用另一个请求把验证码写进同一行。**汇合点是数据库而非进程内存**，
所以哪个 worker 收到验证码都能送达。
- 新增 garmin_mfa_sessions 表（不存密码，密码只活在等待线程的内存里）
- services/garmin_auth.py：start_login / submit_code / cancel
状态机 starting -> awaiting_code -> finishing -> done|failed
- 超时 5 分钟自动放弃，会话 1 小时后清理
- 会话按 user_id 校验，他人拿到 session id 也读不到、提交不了
接口:
- POST /api/garmin/login 发起登录，202 返回 session
- GET /api/garmin/login-status 轮询状态
- POST /api/garmin/mfa 提交验证码
- DELETE /api/garmin/login 取消
前端 DataSync 改为三步：
- 未绑定 -> 输密码「绑定 Garmin 账号」
- 需要验证码 -> 弹出 6 位验证码输入框（inputMode=numeric、
autoComplete=one-time-code，手机可直接从短信自动填充）
- 已绑定 -> 只剩「立即同步」，不再要密码
tests/test_garmin_mfa.py (20 通过):
- stub 的 prompt_mfa 按 garth 的真实方式同步阻塞调用
- 关键用例：验证码直接写进数据库行也能被挂起的线程取到
（模拟验证码落到另一个 worker）
- 无 MFA 的账号不经验证码直接完成
- 验证码错误 / 密码错误 / 等待超时 各自失败并给出原因
- 取消后挂起线程立即释放，不空转到超时
- 密码不出现在会话行里
- 跨用户读取和提交均被拒
全量: 271 passed
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
|
2026-08-23 20:11:45 +08:00 |
|