 yml2213
|
c3fd299f3a
|
test(db): 测试改用真实 MySQL，方言差异不再漏到生产
生产是 MySQL 8、测试是 SQLite，两者的方言差异在本地完全测不出来。今天为此
付出了两次代价：
1. `ORDER BY ck_checked_at ASC NULLS FIRST` 在 SQLite 上完全正常，本地 258 条
全绿，一部署到生产第一次巡检就 1064 语法错误（MySQL 不支持 NULLS FIRST）；
2. P1b 自动重登的结算复用调度器事务读取，在 SQLite 下看不出问题，但在 MySQL 的
REPEATABLE READ 下读到的是批次开始前的快照 —— 10 条实际成功的重登全部被记成
失败。SQLite 的读一致性与 MySQL 不同，这类问题跑一万遍也复现不出来。
改动：
- 新增 tests/support/db.py：测试专用引擎/会话工具，连接串从 .env 读取，
默认指向独立的 douyu_login_test 库；
- 新增 tests/conftest.py：会话级建好表结构，每个用例前后清空所有表做隔离；
- 根 conftest.py 接管连接串设置：它在 pytest 收集阶段最先执行，在这里把
DATABASE_URL 指向测试库，应用模块首次 import 拿到就是 MySQL，不依赖任何
import 顺序（原先这里是 sqlite:// 兜底，改造后会变成「先建 SQLite engine
再打补丁换成 MySQL」，顺序一变就静默跑错库）；
- 21 个测试文件的 setup 样板统一改用共享测试引擎；
- 两个迁移测试改为在临时库 douyu_login_mig_<随机> 上跑完整 alembic upgrade head，
跑完 drop —— 迁移脚本本身也终于在 MySQL 上被验证；
- dev.sh 与 README 的过时说明一并更新（原先写着「不需要 MySQL / .env 配置」；
「测试各自建 SQLite 内存库」）。
安全与易用：
- 测试库名与开发库同名时**直接拒绝运行**（clear_tables 会 DELETE 所有表，
一旦 TEST_MYSQL_DATABASE 被指到 douyu_login 就是数据灾难）；
- 连不上 MySQL 时给出可操作提示（先 ./dev.sh 起库 / 用 TEST_MYSQL_DATABASE 覆盖），
而不是抛一段 SQLAlchemy 原始堆栈。
验收：
- 全量 301 条通过，连跑两次结果一致（隔离有效），耗时约 12.5 秒（原 SQLite 约 3.6 秒）；
- 单文件独立运行通过（不依赖全量执行顺序）；
- `grep -rn sqlite tests/ conftest.py` 已无实际用法；
- **方言确实生效**：临时把一条查询改回 `NULLS FIRST`，13 条测试立刻变红（含运行期
失败），还原即恢复；这条由 test_generated_sql_is_mysql_compatible 长期守着。
代价（已在 README 与规划附录 C.2 记明）：跑测试前必须先有 MySQL，pre-push 钩子
同理；CI 需要 service container。
|
2026-10-02 21:22:08 +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
|
ed6e186655
|
fix(ui,test): 说明巡检与重登的联动关系；修掉一条按分钟偶发失败的测试
看图时发现两个问题：
一、页面上那段说明是 P1a 时代的文案，已经过时且误导：「重登仍由人工在
「CK 检测与重登」页面操作」——P1b 上线后自动重登已存在。两个作业其实是联动的
上下游：巡检把账号标成 invalid，「CK 自动重登」的候选条件正是这个字段，所以
巡检一发现失效、重登作业下一周期就会接手。刻意分成两个作业是为了止损粒度
（巡检只读零风险；重登会真实登录，出问题可单独关掉）。据此改写说明文案，并在
两张卡片上标出「下游：CK 自动重登」/「上游：巡检标记为失效且有 CK 的账号」。
二、jobs 接口新增 pending_relogin：当前有多少条正等着自动重登。页面靠它把
上下游关系显性化 —— 没有这个数字，两个开关看起来像互不相干。计数走重登作业
自己的候选查询，保证「页面显示的待办」和「作业实际会捞的」是同一口径。
顺带修掉 tests/test_douyu_email_code_pick.py 里一条既有缺陷：它用
max(0, now.minute - 30) 构造「30 分钟前的邮件」，分钟数小于 30 时会退化成当前
整点（21:00:12 → "今天 21:00"），只比 now 早十几秒，于是断言随「当前几点」偶发
失败 —— 每小时前 30 分钟必红（已确认在我本次所有改动之前的提交上同样失败，
不是本次引入）。改成真实的时间减法，跨天时用「昨天」。
全量 298 通过。提交时另一路 SQLite→MySQL 的测试改造仍在同一工作区进行，
本次只暂存本功能相关文件。
|
2026-10-02 21:01:17 +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 |
|