 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
|
8310a9115e
|
fix(login): 删除任务不再丢 CK —— 只删不持有 CK 的记录【数据安全】
事故：斗鱼账号的 CK **只存在 `login_tasks.cookie`**（`accounts` 表没有
cookie 列），删掉记录即永久丢失登录态。而列表显示的「状态」是最近一次尝试
（`attempt_status`），于是一条**显示「失败」但实际仍持有有效 CK** 的记录
（status=success + cookie + 上次尝试失败）会被「清空失败」当成垃圾删掉。
修复：
- 批量删除只删空 cookie 的记录，持有 CK 的一律跳过，并在响应里报告跳过数；
- 单条删除遇到持有 CK 的记录直接 409，提示先处理该账号的 CK；
- 前端确认弹窗写明「持有 CK 的记录会跳过」。
顺带修统计口径：分页后 success/failed 只统计当前页，却和「共 N 个任务」
并排显示（曾出现「共 8508，成功 48」）。改走 /tasks/summary 的全局统计。
回归测试补 5 条，专门盯「显示失败但持有 CK」这个事故场景。
|
2026-10-03 10:50:23 +08:00 |
|
|
yml2213
|
a0db26def3
|
feat(login): 任务列表支持分页、跨页全选与一键清空
任务量早就过了单页能装下的规模（库里 1.4 万条，单批就 177 条），但接口
硬编码 limit(200)、前端 pagination={false}，于是「全选」其实只能选到前
200 条，失败任务清不干净。
- 接口加 page/page_size/status：不传 page 时仍返回裸数组（Cookie 页等
老调用方依赖这个契约，不能改）；传了才返回 {items,total}，total 供跨页全选。
- 删除支持 all_matching：按当前筛选条件删全部，不必先翻完所有页去勾。
- 前端：分页控件（20/50/100/200/500，记住选择）、状态筛选、表头
「选择全部 N 条（含其他页）」、「清空失败」一键操作。
两条护栏：
- **pending/running 一律不删** —— 删掉会让批次线程找不到记录；要停批次
走 /stop/{batch_id}。
- 不给任何条件就拒绝删除，绝不默认全删。
顺带：带 join 的 query 不能 bulk delete（SQLAlchemy 会拒绝），改成先查
id 再按主键删。
|
2026-10-03 10:37:52 +08:00 |
|