Files
live-hub-py/tests/test_douyu_task_assigned_optimization.py
T
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

104 lines
3.5 KiB
Python

"""验证 DouyuTask 的 account_assigned_to 字段与任务查询优化。"""
from sqlalchemy.orm import Session
from tests.support.db import init_test_schema, make_test_session
from web.backend.models import Account, DouyuTask, User
from web.backend.routers.douyu import _visible_tasks_query
from web.backend.services.douyu_service import create_douyu_planned_tasks
def test_douyu_task_assigned_to_flow():
from tests.support.db import get_test_engine
init_test_schema()
DouyuTask.__table__.drop(get_test_engine(), checkfirst=True)
DouyuTask.__table__.create(get_test_engine(), checkfirst=True)
db: Session = make_test_session()
try:
# 创建测试客服用户与账号
user_a = User(
username="test_kefu_a",
password_hash="fake",
role="support",
custom_permissions=["douyu:task", "account:view_assigned"],
is_active=True,
)
user_b = User(
username="test_kefu_b",
password_hash="fake",
role="support",
custom_permissions=["douyu:task", "account:view_assigned"],
is_active=True,
)
db.add_all([user_a, user_b])
db.flush()
acc_1 = Account(
username="dy_user_1",
password="pwd",
email="em1@test.com",
email_password="pwd",
assigned_to=user_a.id,
# CK 挂在账号上(2026-10-04 CK 解耦)
cookie="acf_uid=101; acf_auth=fake",
)
acc_2 = Account(
username="dy_user_2",
password="pwd",
email="em2@test.com",
email_password="pwd",
assigned_to=user_b.id,
cookie="acf_uid=102; acf_auth=fake",
)
db.add_all([acc_1, acc_2])
db.flush()
# 1. 验证创建任务时,自动继承 account.assigned_to
batch_id, count = create_douyu_planned_tasks(
db=db,
account_ids=[acc_1.id, acc_2.id],
task_type="query_points",
handbook_scope="elite",
created_by=user_a.id,
)
assert count == 2
tasks = db.query(DouyuTask).filter(DouyuTask.batch_id == batch_id).all()
task_map = {t.account_id: t for t in tasks}
assert task_map[acc_1.id].account_assigned_to == user_a.id
assert task_map[acc_2.id].account_assigned_to == user_b.id
# 2. 验证 _visible_tasks_query 能够精准过滤所属客服
query_a = _visible_tasks_query(db, user_a).filter(
DouyuTask.batch_id == batch_id
)
visible_a = query_a.all()
assert len(visible_a) == 1
assert visible_a[0].account_id == acc_1.id
query_b = _visible_tasks_query(db, user_b).filter(
DouyuTask.batch_id == batch_id
)
visible_b = query_b.all()
assert len(visible_b) == 1
assert visible_b[0].account_id == acc_2.id
# 3. 验证账号重新分配后,关联任务同步变更
db.query(DouyuTask).filter(DouyuTask.account_id == acc_1.id).update(
{DouyuTask.account_assigned_to: user_b.id}, synchronize_session=False
)
acc_1.assigned_to = user_b.id
db.commit()
# 此时 user_b 可以看到 acc_1 的任务
visible_b_after = (
_visible_tasks_query(db, user_b)
.filter(DouyuTask.batch_id == batch_id)
.all()
)
assert len(visible_b_after) == 2
finally:
db.rollback()
db.close()