ericwyuan
|
f6687d2b5d
|
fix(deploy): push.sh 报「部署成功」，但跑的还是旧代码
服务是开机时以 root 起的（DSM 任务计划 → S99garmin.sh），所以 logs/
error.log 和 access.log 归 root。以 ericwyuan 重启会立刻失败——gunicorn
连自己的错误日志都打不开；而 stop.sh 同样杀不掉 root 进程，于是旧 master
继续占着 :8124，start.sh 的健康检查看到 200，高高兴兴报了「started」。
这次 AI 教练部署就撞上了：文件推上去了，接口却一直 404，查了半天才发现
在跑的是几小时前那个进程。
- 重启改走 sudo，和服务实际的运行身份一致（密码问一次，或走 NAS_PASSWORD）
- 健康检查加一条：只有 200 不算数——那正是旧 master 会给的答案。比对重启
前后 gunicorn 的 pid，没变就报错退出
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 14:11:17 +08:00 |
|
ericwyuan
|
4d55fb4776
|
chore(deploy): 别把 macOS 的 xattr 塞进 tar，群晖读不懂只会刷警告
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 09:09:21 +08:00 |
|
ericwyuan
|
1c48435b9d
|
chore(deploy): NAS 的 ssh 端口是 2222
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 09:05:35 +08:00 |
|
ericwyuan
|
41b7ae82e4
|
fix(sync): 「全部历史」真的拉全部历史，自动同步不再每次静默失败
四个独立的 bug 叠在一起，表现为「只同步两天、没有进度」：
* 前端 `...(days ? { days } : {})` 把 days=0 当成未传。「全部历史」
存的就是 0，请求体里根本没有 days，后端退回 7 天默认值。
* scheduler 用 `s[0]` 读 query_one 返回的 dict，抛 KeyError 后被
per-account 的 except 吞掉。只要用户存过一次设置，每 30 分钟的
自动同步就一次都没成功过——库里那 2 天全是手动点出来的。
* 增量同步查 `health_daily`（表其实叫 health_data），后台线程直接
死掉，状态永远卡在 syncing，进度条不动。
* UI 完全不看 /sync 的返回值，rate_limited 时按钮点了没反应；轮询
结束时又把 rate_limited 归进 else 分支报「同步完成」。
顺带：
* 日循环遇到 429 立即退避并保留已拉到的天数，而不是当成「跳过一天」
继续往下捶 700 天——这正是之前限流死循环的来源之一。
* 定时循环显式传 SYNC_DAYS。历史范围按 UI 文案只描述手动全量同步，
让半小时一次的 tick 重拉 730 天必然把限流撞得更深。
* 短同步逐天上报进度（原来每 5 天一次，7 天的同步全程停在 0）。
* /sync 路由重复解析 body，空 body 会 None.get 崩。
* 4 个 StubGarth 缺 configure()，7 个测试在此之前一直是红的。
新增 deploy/push.sh：NAS 只认密码，脚本开一个 ssh 复用连接，密码只
输一次，后面推送 / 重启 / 健康检查全走它。不碰 .env、.venv 和数据库。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-01 08:11:24 +08:00 |
|