 yml2213
|
00125fbfc4
|
refactor(account): S2 读写一次切换 —— CK/健康/重登彻底搬到账号，登录记录退化为历史
S1 加好了列，本提交把**读与写一起切**过去。这是设计里「同一份数据的读与写必须
在同一个提交里切」的要求：先切读或先切写都会出现「写账号、读记录」的中间态，
跑起来不报错，只是默默用错数据。
## 核心改动
**判定「谁有 CK」不再借道登录记录**
- `cookie_holding_filter()` / `cookie_operable_filter()` / `cookie_holding_account_ids_query()`
/ `visible_douyu_task_accounts()` 全部改为作用于 `Account`；
- `cookie_operable_filter()` 的「在途排除」仍查 `login_tasks`（那是**某次尝试**的属性），
用 `NOT EXISTS` 子查询 + 迁移 0042 新增的 `(account_id, attempt_status)` 索引；
- 删除死代码 `latest_cookie_login_task()`；`latest_cookie()` 改为直接读账号。
**CK 写入**
- `_write_login_success()` 写 `Account.cookie / cookie_updated_at / cookie_source`；
- `_mark_attempt_failed()` 改看**账号**有没有 CK（决定是否沿用旧的失败语义）；
- 检测模式的 `task.cookie = ""` **不再清空账号的 CK**（见下「行为变更」）。
**自动化作业按账号调度**
- `ck_health`：`_select_tasks` → `_select_accounts`，`db.query(Account)`；新增
`count_remaining()`（刻意不带 LIMIT，否则积压数恒等于批次上限）；
- `ck_relogin`：同样按账号选行；结算改为「账号 + 本轮尝试记录」，
退避进度写账号；`settle_fresh_results(batch_id)` 按 `attempt_batch_id` 配对，
`run_ck_relogin` 把 **account_ids** 交给 runner；
- 顺带让**没有任何登录历史的账号**也能被巡检/重登（以前它们永远进不了队列）。
**登录批次**
- `LoginBatchRunner` 去掉 `relogin_task_ids`，重登与登录统一走 `account_ids`；
- 批次行复用逻辑重写：只保证「同一账号不并发两行」，不再关心「哪一行持有 CK」。
失败行复用同时看 `attempt_status`（账号有 CK 时 `_mark_attempt_failed` 刻意不动
`status`，只看 status 会永远命不中 → 每次失败刷一行）。
**删除护栏语义变更（用户可感知）**
- 去掉「持有 CK 的记录不可删」——CK 在账号上，删历史不再影响登录态，历史终于可清理；
- **保留**「在途尝试不可删」（批次线程正拿着那条记录）。
## 行为变更（需评审）
1. **账号检测不再清空 CK**。旧代码在 check 模式写 `task.cookie = ""`，而那时记录的
cookie 就是账号唯一凭证 —— 一次「批量检测」会把账号登录态删掉。解耦后
「检测账号凭据」与「CK 是否有效」本就是两件事（后者归 `ck_health` 判），
继续清空等于凭空制造不可逆的数据丢失（重登当前成功率极低）。
2. **Cookie 页的记录单位从「登录记录」变成「账号」**，所有接口的 id 入参/出参
变成 `account_id`；`DELETE /cookies/{id}` 清的是该账号的 CK，**必写审计**。
3. 重复检测从「同一账号多行持 CK」改为「**同一个 CK 出现在多个账号上**」——
后者才是真风险（两个账号共用一个登录态）。用 sha256 指纹分组：
CK 是 AES-GCM + 随机 nonce 加密，**同一明文每次密文都不同**，比密文永远比不出重复。
## 修掉一个真实并发缺陷
`_write_login_success` 原先被传入 `self.db`（runner 主会话），而它是在**工作线程**里
用 `worker_db` 执行的。`emit()` 会往 `account_events` 插一行，其 `account_id` 外键对
`accounts` 那一行加**共享锁**；这把锁加在另一个会话上，紧接着本会话的
`UPDATE accounts SET cookie=...` 就被自己人挡住 —— 实测 **50 秒后
`Lock wait timeout exceeded`，登录明明成功却写不回 CK**（改造前 UPDATE 打在
`login_tasks` 上所以没撞上）。改为传 `worker_db`：事件本就该和状态变更同事务提交，
顺带修掉跨线程共用一个 Session 的隐患。
## 验证
- 全量 pytest **368 passed / 6 skipped**；迁移链 3 passed；
- 前端 `tsc -b && vite build` 通过；
- `ruff check` / `ruff format --check` 全绿（顺带修掉 main 上遗留的 F821）；
- 新增/改写的关键回归：**删掉全部登录历史后账号的 CK 与健康状态仍在**、
**无登录历史的账号也能进巡检队列**、结算不碰 CK、删除护栏改为在途语义。
仍未做（设计里排期的后续阶段）：`account_lifecycle` 状态收口（S3）、事件发射点补齐（S4）、
业务事实直发事件（S5）、账号页重构（S6）。注意 `status` 目前只有模型默认值与迁移回填，
所以 `disabled/archived` 还没有任何写入方——S3 落地时要把自动化选行的状态过滤一起补上。
|
2026-10-04 14:10:13 +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 |
|
|
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 |
|