 yml2213
|
d6c6113112
|
fix(automation): 被重启打断的轮次记为 interrupted，不再混进 failed
部署重建容器会打断正在跑的作业，那轮永远写不回结果，由启动时的
cleanup_orphan_runs 收尾。之前收尾成 failed，于是页面上一片红 —— 但这并不是
作业本身的失败：账号侧的 CK 一个没丢（旧 Cookie 已保留），被中断的账号也会按
退避自动重试。混在 failed 里会掩盖真正的失败（如 SQL 语法错误）。
改为独立状态 interrupted，前端用中性灰显示「被中断」，与红色的「失败」区分开。
|
2026-10-02 22:08:18 +08:00 |
|
|
yml2213
|
df62898d22
|
fix(automation): 调度心跳与作业周期解耦，修掉系统性跳轮
线上现象：同一页面上「CK 自动巡检」的最近运行是 21:45:34，而「下次运行」显示
21:50:34 且已经过去了 —— 巡检明明只要 19 秒，却总是等在那里。
根因是把心跳周期直接当成了作业周期：TICK_SECONDS=300 既是「循环多久醒一次」，
又被写进 next_run_at = 作业结束 + 300s。两者同频会系统性跳轮：
心跳 t=0 ck_health 19 秒跑完 → next = 5:19
心跳 t=5:00 差 19 秒没到点 → 整轮空转，什么都不做
心跳 t=10:00 才真正跑到
于是作业实际是每 10 分钟一轮，而不是设计的 5 分钟；只要作业耗时不是刚好 0，
就会稳定地"差一点点"被跳过。两个作业共享同一个心跳时，还会互相把对方的到期
时刻推后。
改动：
- 拆成两个常量：TICK_SECONDS=30（心跳，只做「有没有到点的作业」检查，几乎不
耗资源）、JOB_INTERVAL_SECONDS=300（作业周期，跑完一轮后隔多久再跑）。
- next_run_at 改用 JOB_INTERVAL_SECONDS。
- /api/automation/jobs 的 scheduler 同时暴露两个值；启动日志一并打印。
- 页面：「单账号重检间隔」加 tooltip 说明它不决定调度频率（它只控制同一行多久
重检/重试），避免和调度周期混淆。
回归测试（3 条）：心跳必须比作业周期密至少 4 倍；周期未到时连跳多次心跳都不跑；
把 next_run_at 拨到过去后下一次心跳必须跑到。
全量 304 通过。
|
2026-10-02 21:57:41 +08:00 |
|
|
yml2213
|
34d667cba0
|
fix(automation): 启动时收尾卡在 running 的运行记录
作业是在调度线程里同步跑的：进程一重启（部署、崩溃、手工重启），那一轮就再没
机会写回结果，automation_runs 会永远停在 running，页面上一直显示「执行中」。
登录任务早有孤儿清理，运行记录原先漏了。
线上就是这么暴露的：部署时重建容器打断了正在跑的 ck_relogin 第 14 轮，重启清理
把 20 个在途账号标成了「重新登录中断（旧 Cookie 已保留）」（这部分是对的），
但 run 14 本身永远卡在 running，detail 为空。
新增 cleanup_orphan_runs()，在启动清理链里调用：把所有 running 的运行记录收尾为
failed + finished_at + 「服务重启中断」。如实记为 failed 而不是 success —— 那轮
确实没跑完；被中断的账号由各自的孤儿清理负责标记并按退避重试。
新增回归测试：只有 running 的被收尾，已完成的不受影响。
（另一件事一并说明：上一次部署我报告「零中断」是验证过早 —— 检查时部署的 up -d
还没执行到。实际情况是 mysql 未被重建（达到了本次改动目的），但应用容器因镜像
变化被正常重建，因此打断了那轮重登。）
|
2026-10-02 21:35:42 +08:00 |
|
|
yml2213
|
7aaaeebe2b
|
fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔
P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是
作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过
一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。
按规划原意修正：
- TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮；
- next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds；
- interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就
是这么用的，无需改）；
- 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟，
冷启动约 5.4 小时覆盖全库，稳态每轮一百多条；
- 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清
「每 5 分钟跑一轮」，避免运维误以为是作业周期。
同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线
步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。
|
2026-10-02 19:54:31 +08:00 |
|
|
yml2213
|
f745a61df1
|
feat(automation): CK 自动巡检（P1a），只检测不改 CK
后台原本靠人工逐批点「CK 检测」发现失效账号，1.2 万个账号根本盯不过来。
P1a 把「哪些账号失效了」自动化：自动挑久未检测的账号、调现成检测接口、
把结果写回 ck_check_*。**本作业不替换任何 CK**，重登仍由人工点，符合规划里
「先做只读/只提示，确认无误再做自动动作」的渐进上线原则。
实现：
- 迁移 20261002_0037：automation_jobs / automation_runs 两张表，
login_tasks 加 relogin_attempts / relogin_next_at / relogin_last_error
（为 P1b 备好），accounts 加 auto_managed（特殊账号不参与自动化）；
- services/automation/scheduler.py：进程内调度线程，60s tick，状态全部落库
（重启不丢调度进度、不重复跑轮）；AUTOMATION_ENABLED 默认关闭，作业开关
也默认关闭；ensure_jobs 只补缺失行、不覆盖运维改过的配置；
作业异常只记 failed，不拖垮调度线程；单容器 --workers 1，无需分布式锁；
- services/automation/jobs/ck_health.py：选行口径与人工检测一致
（cookie_holding_filter：持有 CK 且无在途尝试），叠加久未检测、
auto_managed、batch_size，按 ck_checked_at 升序（最久没查的优先）；
只写 ck_check_status / ck_check_result / ck_checked_at；
- routers/automation.py：GET /jobs、PATCH /jobs/{key}、POST /jobs/{key}/run、
GET /runs；新增权限点 automation:view（运营可看）与 automation:manage
（仅超管），改配置与手动触发都写审计；
- 顺带补 POST /api/login/batch 的审计（此前批次是谁发起、多少账号无据可查）；
- 前端 /automation 页：作业卡片（开关/周期/单轮条数/并发）、运行历史、
「立即跑一次」；总开关未打开、调度线程未运行时给明确提示。
验证：
- 22 条新测试覆盖调度器行为（只跑到点的、异常不抛出、下轮时间、配置不被重置）、
选行条件（在途尝试/auto_managed/间隔/batch_size）、接口与权限，其中一条
专门断言巡检后 cookie/status/message/attempt_status 一字未动；
- 全量 257 条通过；前端 tsc 与构建通过；
- 端到端用 3 个真实账号跑真实斗鱼接口：巡检结果与直接调 check_douyu_cookie
逐条一致（3/3 valid），CK 与尝试状态全程未变。
顺带修掉一处会炸生产的坑：DB 时间列读出来是 naive UTC，直接与
datetime.now(UTC) 比较会 TypeError，现统一走 _as_utc() 补时区。
|
2026-10-02 19:47:41 +08:00 |
|