 yml2213
|
b34c1ff5f3
|
fix(automation): 重登结算改用新事务读取，修掉「成功被记成失败」
线上第一轮自动重登（10 条）报告「成功 0 / 失败 10」，但库里这 10 条的
attempt_status 全是 success —— 账号其实都救回来了，是结算读错了。
根因是 MySQL 的隔离级别：默认 **REPEATABLE READ**。调度器传进来的会话在挑候选
时就已经开了事务，而结算复用了这个会话去读 runner（另一个会话）刚提交的结果；
同一事务里重新查询只会看到事务开始时的快照，于是全部读成「未成功」。SQLite 的
读一致性与 MySQL 不同，所以这类问题在 SQLite 上跑一万遍也复现不出来。
后果不只是统计错：失败的账号会被写退避时间，其中 2 条还被判成「极验」进了待
人工队列 —— 等于把救回来的账号又标成需要人工。
改动：
- 新增 settle_fresh_results()：自己新开一个会话读结果并结算，绝不复用调度器的
事务；run_ck_relogin 改用它。
（另一路 SQLite→MySQL 的测试改造已把测试套件真正跑在 MySQL 上，本次新增的回归
测试 test_settlement_sees_other_session_commit 正是靠这一点才守得住：它先让一个
会话开着事务，再由另一个会话提交成功，断言结算必须读到成功。）
|
2026-10-02 21:09:48 +08:00 |
|
|
yml2213
|
2c532df14f
|
fix(automation): 待重登积压数不再被批次上限截断
页面上「待重登候选」显示 10 —— 那只是 ck_relogin 的 batch_size，不是真实积压。
根因是我用作业的候选查询取 count，而那个查询带 LIMIT batch_size，count 自然
被截断在批次上限；线上实际有一千多条待重登，页面却恒显示 10。
改为独立的 count_pending_relogin()：同一套资格条件（invalid + 有 CK + 允许自动
管理 + 未转人工 + 未超每日上限），但不带 LIMIT，也不按退避窗口过滤 —— 退避是
「什么时候试」的细节，不影响「还有多少要处理」。
新增测试：批次上限为 10 时，25 条积压必须报 25。
另：本次一并还原了 ck_health.py 里被外部改动引入的回归 —— 有人把选行排序改成
text("login_tasks.ck_checked_at ASC NULLS FIRST")，那是逐字透传给数据库的片段，
而 MySQL 不支持 NULLS FIRST（今天线上就是这么炸的 1064）。已恢复成可移植写法，
test_generated_sql_is_mysql_compatible 会拦住这类改动（本次正是它先报的红）。
全量 298 通过。
|
2026-10-02 21:05:18 +08:00 |
|
|
yml2213
|
8fc8e623b9
|
feat(automation): CK 自动重登（P1b）+ 失败分型与待人工队列
P1a 的巡检只产出「谁失效了」的清单，不兑现修复：1,356 个失效账号仍要人工逐个
选集→点重登→过滑块。线上实测 20 个失效账号重登 20/20 成功（2 分 13 秒、零极验），
证实失效是会话级过期而非凭证问题，可救量约 1,350。
后端：
- 迁移 20261002_0038：login_tasks 加 relogin_failure_kind（枚举），供作业决定
「继续退避重试」还是「转人工」；不用 attempt_message 做字符串匹配（文案一改
就失效，页面也要按类型筛选）；
- jobs/ck_relogin.py：
- 候选 = 巡检判定 invalid + 允许自动管理 + 无在途尝试 + 退避到期 + 未超每日上限
+ **未转人工**（极验/凭证问题不再自动重登）；
- 复用 LoginBatchRunner(mode="relogin")，成功才替换 CK（沿用既有安全语义）。
自动化身份取最早的超管做 created_by，权限给 login:view_all 以免受归属限制；
总时长上限压到 240 秒，避免长时间占住调度线程；
- settle_results() 独立成纯函数便于单测：成功清空退避状态；失败按分型分流 ——
captcha/credential 转人工（不排期）、email_quota 退避到次日零点+随机抖动、
email_code/interrupted/network 走 1h→3h→12h→24h 阶梯；次数用尽也停下等人工；
- 未知文案默认按可重试处理（有每日上限兜底），别把可能只是抖动的账号推给人工；
- 注册第二个作业「CK 自动重登」（batch 10 / 并发 3，**默认关闭**）；
- 新增 GET /api/automation/manual-queue：按原因分组列出待人工处理的账号。可重试
类型但已无下次排期的（次数用尽）单独成组 —— 否则会混进「验证码失败」里，客服
看不出这个已经不会再自动试了。
前端：
- /automation 页新增「待人工处理」卡片，按分型分组展示（极验要过滑块、凭证要核对、
次数用尽要人工确认），各带账号与最近失败原因。
测试：新增 26 条（分型顺序陷阱「上限」优先于「验证码」、退避阶梯、配额退避次日、
候选筛选、MySQL 方言编译、结算、待人工队列分组）。
提交前全量 297 通过、ruff 全绿、前端 tsc 通过。
注意：提交时另一路「测试改用 MySQL」的改造正在同一工作区进行，本次刻意只暂存
本功能相关文件，未触碰 tests/conftest.py、tests/support/ 及对方已转换的测试文件。
|
2026-10-02 20:51:19 +08:00 |
|
|
yml2213
|
f8c5e896d4
|
fix(automation): 巡检区分「查不到」与「失效」，并在大面积失败时自动暂停
P1a 原本把「检测没通过」一律写成 invalid。但 check_douyu_cookie 的失败分两类：
斗鱼明确回「未登录/登陆异常」（CK 真失效），以及请求超时/响应异常（我们查不到）。
一视同仁的后果是：斗鱼接口抖动或被风控时，每 5 分钟 200 个、一小时就能把两千多个
好账号标成失效，客服会误判成「CK 大面积挂掉」。规划里的失败率熔断只给了 P1b，
P1a 漏了。
改动：
- 新增 classify_result()：valid / invalid（命中斗鱼鉴权类说法）/ error（其余）；
- error 时**不覆盖该行原来的 ck_check_status**，只更新 ck_check_result（带
verdict 字段）与 ck_checked_at，并计入本轮 skipped；
- 一轮 error 占比 > 30% 且条数 >= 20 时自动把作业 enabled 置 false，message 与
detail.paused 写明原因，避免继续污染；
- 真实死号占比高**不触发**暂停 —— 首轮 100% invalid 是预期情况（选行「从没检测过
的优先」，积压的是两个月前批量导入、attempt_status 为空、从未登录的陈旧账号，
生产实测 200 条错误信息一致为斗鱼侧「用户未登录」）。
新增 6 条测试：分类正确性、error 保留原结论、异常不再标失效、大面积失败自动暂停、
真实死号不暂停。全量 271 条通过。
|
2026-10-02 20:35:30 +08:00 |
|
|
yml2213
|
3d5d0f551f
|
fix(automation): 去掉 MySQL 不认的 NULLS FIRST，排序改用可移植写法
生产 MySQL 上手动跑第一轮就报 1064：
You have an error in your SQL syntax ... near 'NULLS FIRST, login_tasks.id ASC'
NULLS FIRST 是 PostgreSQL/SQLite 语法，MySQL 不支持。本地测试全绿是因为跑在
SQLite 上（它认识这个语法），属于方言差异漏网 —— 生产是 MySQL、测试是 SQLite，
行为测试覆盖不到这类问题。
改成 `ck_checked_at IS NULL DESC, ck_checked_at ASC, id ASC`：三个方言下语义
一致（没检测过的优先）且都是合法 SQL。顺带把选行查询抽成 build_select_query，
便于按方言编译做回归。
新增回归测试：用 MySQL 方言 compile() 选行 SQL，断言不含 NULLS FIRST/LAST，
且「没检测过优先」用可移植写法表达。
规划附录 C.2 记下这条：写 SQL 前先确认方言；P0 连的是 order_site 的 PostgreSQL，
项目里已经出现 MySQL / SQLite / PG 三套方言。
|
2026-10-02 20:14:49 +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 |
|