2 Commits

Include renames

Author	SHA1	Message	Date
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