dachui/live-hub-py
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
589 Commits 3 Branches 0 Tags
dev
Commit Graph
27 Commits
Author SHA1 Message Date
yml2213 18bc7be4b1 feat(pool): 账号自动分配与回收（租约 + 补给链 + 独立工作台） 
在既有「管理员分配 → 客服导入工作台 → 手动选号」之外**新增**一条
「客服选皮肤 + 数量 → 系统分配账号 + 按需补积分 → 用完自动收回」的路径。
旧路径只做并集与可选参数扩展，行为不变（有用例守着）。

- 归属与使用权分离：新增 account_leases（生成列 + 唯一索引，并发抢号由数据库裁决），
  assigned_to 收窄为管理员/运营的维护责任；客服可见范围扩为「名下 ∪ 租用中」
- account_pool 服务：候选筛选、两梯队排序（先花快过期的 / 先选充值少的）、
  供给与成本预估、租约领取/释放/回收
- 补给链：查余额 → 充鱼翅（单次 ≤800 元，超限拆单）→ 赠精英令 → 兑换；
  运行期两道闸门：_skip_when（余额已够就别再花钱）、_depends_on（前置未成功就跳过）
- 转人工：鱼翅支付等 10 分钟未到账转 manual_required，租约先不还；
  account_lease_reaper 兜 TTL 到期 / 漏释放 / 孤儿批次
- 运营流水：业务事件补 actor_id = task.created_by；账号详情页展示操作人、渠道
  与租赁记录
- 新工作台：/douyu/pool + 菜单「账号分配台」（新建，不改造旧工作台）
- 修复 D1：官方补录的兑换事件漏写 subject_key（10,612 条主键为空），
  会让 365 天同皮肤规则漏判 87% 的历史；补代码 + 回填脚本
- 迁移 20261007_0052；权限 account:pool_use / account:pool_admin

测试：766 passed, 6 skipped（改动前基线 727）；ruff 与 tsc -b 干净。
设计稿与实施记录：docs/设计-账号自动分配与回收.md
 2026-10-07 12:29:08 +08:00
yml2213 ccd05cba9c feat(overview): 关掉和平小店查询 + 修电竞「已开通」不落库 
## ① 和平小店总开关（默认关）

小店目前是**关闭状态**，但不跳过的话一键查询仍会对每个账号发小店请求，
结果 100% 失败 —— 实测 200 个账号里 `exchange_records_peace` 失败 **195 次（100%）**：

    Livelink登录态校验失败

100% 意味着不是账号问题。这既淹掉真错误、又让人以为出故障。

新增 `douyu_config.peace_enabled`（迁移 `0050`，**默认 False**）。
关着时**完全跳过**小店的所有请求（绑定 + 兑换记录），并且**不记 errors** ——
「配置成关的」和「查失败」是两回事，混在一起会让 errors 失去意义。

将来小店恢复，在后台打开这个开关即可；打开后小店失败仍会**如实暴露**
（有用例专门钉住这一点，别把开关当成遮羞布）。

## ② 修：电竞手册「已开通」不会被一键查询更新

用户问"电竞到期时间为什么拿不到"，查下去发现**两层**：

**第一层不是 bug**：那 200 个账号 `esports_opened` 全是 0（没开通电竞手册），
所以 `expireTime="0"`、没有到期时间可存。注意
**"电竞已绑定角色"≠"电竞手册已开通"**。实测 `opened_but_no_expire = 0`，没有异常。

**第二层是真 bug（不对称）**：

    _refresh_elite_handbook   → 写 account.elite_opened  ✅
    _refresh_esports_handbook → 不写 account.esports_opened ❌

`esports_opened` 只在"开通"任务里被设置，所以**详情页电竞的「已开通/未开通」
根本不会被一键查询更新**。已改成与精英对称（口径同 create_esports_qr：
`manual_type >= 1` 即已开通）。

## 测试（+2）

- 小店关着时：**不发**小店请求、**不查**小店绑定、**不记** peace 相关的 errors，
  且结果里标明 `peace_skipped`
- 小店打开时：失败**仍然如实暴露**（反向用例，防止开关变成遮羞布）

## 验证（本地）

TZ=Asia/Shanghai **620 passed / 6 skipped**；ruff 全绿。
 2026-10-04 20:59:17 +08:00
yml2213 d285196287 feat(account): 账号「一键查询」（异步 + 批量）—— 含一次重要的判定修正 
按 `docs/设计-账号一键查询.md` 实现。异步任务、支持批量（后端每账号一条任务）。

## 功能

- 新任务类型 `query_account_overview`：**只读**聚合查询，不改账号状态、不发事件
  （纯查询不是「事实」，按既有设计例行查询不进时间线，否则会刷屏）
- 一次拉全：鱼翅 / 钱包兑换余额 / 积分（含到期）/ 精英宝典 / 电竞手册 /
  **官方兑换记录** / 限兑商品，并**重点标出「兔兔白日梦」「狂战萌兔」是否已获得**
- **单项失败不整体失败**：账号没绑电竞手册是常态，失败只写进 `errors` 并在 UI
  **如实展示** —— 避免「没查到」被读成「没有」
- 批量：`create_douyu_planned_tasks` 本来就是每账号一条任务，前端加「批量一键查询」
- 前端：详情页一键查询卡片 + 结果面板（两个套装单独高亮）；任务页结果自动弹面板；
  三个工作台的快捷操作/类型集合都加了

## ⚠️ 修正：判定「是否已获得」用错了依据

设计文档第一版说「`storeStatus == 0` → 已拥有」，依据是
「账号 558（兑换过）count=0，账号 15407（没兑换）count=96982」。

**这是错的。** 那两条记录分别取自 **2026-08-01** 和 **2026-10-04**，相隔两个月 ——
我把**时间差异**当成了**账号差异**。

**同一时刻**同时查 558 / 607（都兑换过）和 15507（没有），
商品项的**所有字段完全一致**，`preExchange.isExists` 也都是 0；
`count` 的取值分布是 0/98746/103350/109832…，**随时间变化 = 全局库存**。
用它判「这个账号有没有」必然给错结论 —— 而对高价值资产给错结论是本功能最不能接受的。

**正确依据：`exchange_records(manual_id)`**（斗鱼官方的**账号级**兑换记录）。
真实斗鱼实测：

| 账号 | 官方兑换记录 | 判定 |
| --- | --- | --- |
| 558 | 破片手榴弹-兔兔白日梦 | **已获得 ✅** |
| 607 | 破片手榴弹-兔兔白日梦 | **已获得 ✅** |
| 15507 | （0 条） | 未获得 ✅ |

同时刻三者看到的兔兔白日梦库存**都是 96956**（全局），兑换记录却区分得干干净净。

顺带发现：同一件东西有多个商品名（`套装-兔兔白日梦`、`破片手榴弹-兔兔白日梦`），
所以按**核心词子串**匹配整个名字家族。

商品列表的 `score`/`count`/活动时间仍展示，但明确是**全局**信息
（「现在还能不能换、要多少分」），与「该账号是否已获得」分开。

## 测试

`tests/test_account_overview.py` 22 条，含**回归用例**：
`test_global_stock_never_implies_owned`（全局售罄不能推出账号拥有）——
正是第一版踩的坑。另有失败隔离、只读性（不发事件/不改状态）、
批量每账号一条任务、`missing` 不被静默丢弃。

## 验证

- `TZ=Asia/Shanghai` **574 passed / 6 skipped**；`TZ=UTC` 27 passed
- ruff 全绿；前端 build 通过、lint 0 errors
- **真实斗鱼端到端**：三个账号各跑一次真查询，8 项全部成功（`errors: []`），
  已获得/未获得判定全部正确
 2026-10-04 19:07:35 +08:00
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 7790be4e04 perf(douyu-tasks): 为斗鱼任务增加归属客服索引字段，彻底消除全表 filesort 慢查询 
1. 数据库新增迁移 20261003_0040，在 douyu_tasks 表增加 account_assigned_to 字段，并创建 (account_assigned_to, handbook_scope, id) 与 (account_assigned_to, id) 复合覆盖索引；
2. 迁移脚本自动回填历史 24 万条任务的所属客服 ID；
3. 任务服务与账号路由联动：创建任务时自动继承 account_assigned_to，修改账号分配时同步更新关联任务归属；
4. 斗鱼任务查询路由 _visible_tasks_query 改为通过 account_assigned_to 复合索引过滤，消除与 accounts 表的跨表关联与临时表全量文件排序；
5. 新增 test_douyu_task_assigned_optimization 单元测试并通过整链迁移与回归测试。
 2026-10-03 13:10:59 +08:00
yml2213 99db772ddd feat(douyu): 精英宝典支持查询开通状态，开通前先校验且不再误判到账 
线上两个问题：工作台看不到账号有没有开通精英宝典；点开通时二维码会「闪一下
就变小」——大图弹窗 2~4 秒后自动关闭，只剩列表里 56px 的小二维码。

根因：
- getUserInfo 的 manualType/expireTime 才是开通状态的权威口径，但只有兑换
  流程用过一次，没有任务类型对外暴露；前端只看积分列，而「开通后积分花完」
  和「从未开通」都是 0 分，区分不了（实测 13456 manualType=1/score=0）；
- 开通前不查状态，且到账判定写成「积分 >= 300」：账上本来就有 680 分的账号
  在出码后第一轮轮询就被判成功，前端按 paymentArrived 自动关掉了弹窗。

改动：
- 新增任务类型 query_elite_status：查 manualType/manualScore/expireTime 并
  落库到 accounts.elite_opened / elite_expire_time（迁移 20261001_0036），
  精英工作台加查询按钮与「宝典状态」列（已开通+到期 / 未开通）；
- create_elite_qr 开通前先查状态：已开通直接判成功、不再生成支付码（方案 A），
  既消除二维码闪现，也避免给已开通账号开出真实支付单；
- 到账判定改为「积分比开通前增长」，基线用与轮询同源的 credit/balance 取，
  取不到基线才退回旧口径；
- 支付弹窗不再自动关闭：到账/失败/停止都在弹窗里给结论 + 手动关闭；列表小
  二维码在任务进终态后隐藏。

新增 9 条测试覆盖上述行为，回退 runner 时其中 8 条失败。
 2026-10-01 19:08:25 +08:00
yml2213 6a25097412 fix(douyu): 替换 CK 是最后一步，只有登录成功才写回记录 
上一版把可见性改成「记录里还有 CK」，账号不会再消失，但根因还在：批次启动
时就把复用的成功记录改成 pending（旧 CK 仍在），停止或失败后没人恢复状态，
记录一直显示成一次没完成的登录。

按「替换 CK 是最后一步」把两者拆开：

- login_tasks 新增 attempt_status / attempt_message / attempt_batch_id /
  attempt_at，批次只写 attempt_*，status/cookie/message 只在登录成功时更新；
- _begin_attempt 只登记尝试，_mark_attempt_failed 只记录失败（已有 CK 的记录
  原样不动），_write_login_success 是唯一替换旧 CK 的入口；
- 停止批次、代理不可用、登录异常、进程重启清理全部改为收敛 attempt_*，
  因此停止一个批次不可能再让账号失去 CK；
- 复用的记录改用「持有 CK 的记录」，不再创建第二条记录，失败记录在无 CK 时
  才复用；
- 登录任务列表/统计按 attempt_* 展示「这次登录怎么样了」，批次筛选同时匹配
  attempt_batch_id；CK 操作页的重登状态也从 attempt_* 映射；
- 迁移 20261001_0035 归一存量数据：持有 CK 的记录 status 统一为 success、
  历史状态搬进 attempt_*，无 CK 且卡在 pending/running 的收敛为 failed。

新增测试：批次失败/停止不碰旧 CK、成功后替换 CK、列表展示尝试状态、
迁移存量数据归一。
 2026-10-01 18:29:49 +08:00
yml2213 64c399617a fix(douyu): 账号只要还持有 CK 就不再从工作台消失 
线上事故：分配给客服的账号（如「远行者103」）在斗鱼工作台与 CK 列表里
查不到，只有账号管理里还能搜到。原因是可见性判定写成了
LoginTask.status == "success"，而按设计保留旧 CK 的三种状态都不再是
success：

- 普通登录批次启动时会把复用的成功记录置为 pending/running（旧 CK 保留），
  批次被停止或失败后一直停在 pending，账号永久消失；
- CK 重登失败置为 relogin_failed（旧 CK 保留），账号从工作台消失；
- 普通登录失败置为 failed（复用记录的旧 CK 未清空），同样消失。

线上现状：12545 个账号持有 CK，但只有 11703 个能出现在工作台，842 个
（644 重登失败 + 176 排队中 + …）对客服和管理员都不可见。

改动：
- douyu_service 新增 cookie_holding_filter()/latest_cookie_login_task()，
  以「记录里还留着 Cookie」作为唯一判据，并抽出 LOGIN_IN_FLIGHT_STATUSES
  与 cookie_operable_filter() 供检测/重登入口复用；
- 斗鱼工作台账号列表、任务账号校验、账号管理 has_cookie 筛选、分配校验与
  概览、CK 管理/操作列表、首页 CK 统计统一改用该判据；
- 工作台取 CK 从 latest_success_login_task 换成 latest_cookie_login_task，
  保证重登失败/排队中的账号仍能被任务正常执行；
- 新增 cleanup_orphan_login_tasks()：进程重启后把遗留的 pending/running
  收敛为 failed 并保留旧 CK，避免页面永久显示排队中。

新增回归测试覆盖上述状态下的可见性、可执行性与启动清理。
 2026-10-01 18:18:02 +08:00
yml2213 b58c6b4357 执行 Ruff 安全自动修复 2026-08-31 10:28:14 +08:00
yml2213 c891ac982e type: 收敛测试 schemas 与协议层类型 2026-08-30 20:35:08 +08:00
yml2213 6ded82ac8b fix(douyu): reject invalid activity cookies 2026-08-28 15:51:59 +08:00
yml2213 9ee4e49a50 feat(douyu): support elite handbook lock orders 2026-08-28 14:06:11 +08:00
yml2213 e2a45b7893 优化斗鱼充值日志与配置 2026-08-14 11:27:53 +08:00
yml2213 902e669614 功能: 接入鱼翅供应商直充渠道 2026-08-13 21:11:20 +08:00
yml2213 cf3fe68de3 功能: 按用户同步斗鱼工作台 2026-08-13 15:47:07 +08:00
yml2213 8b7ff770e2 fix: preserve xpd purchase records in task results 2026-08-08 21:56:39 +08:00
yml2213 a342dddcb6 feat: add xpd purchase records view 2026-08-08 21:41:44 +08:00
yml2213 ec5eb637bb feat(douyu): 支持和平小店商品兑换 2026-08-07 22:47:13 +08:00
yml2213 a515ea6e0a feat(douyu): 和平小店扭蛋碎片查询 + 深色模式修复 + 任务状态 WS 即时推送 
- 碎片: 新增 query_xpd_fragments 任务, 复用 e语言 gamecoin 接口取扭蛋币 jb2,
  账号已存角色回退(规避 Livelink 风控), accounts.xpd_fragments 字段与迁移
- 列表: 和平小店移除鱼翅/限制兑换/换绑时间列, 新增扭蛋碎片列;
  操作区硬编码白底改用 theme token, 深色模式适配(三个手册共用)
- 轮询: 任务状态经 WS(level=task)即时推送(二维码/绑定进度即时展示),
  pending/running/终态全覆盖, REST/WS 载荷统一 douyu_task_payload,
  raw 快照递归剥离, HTTP 轮询降频 5s/30s 兜底
 2026-08-06 20:21:28 +08:00
yml2213 c05c0e044e fix(douyu): 优化和平小店绑定逻辑 2026-08-06 18:48:29 +08:00
yml2213 5f63d77dc3 feat(douyu): 和平小店绑定功能(生成绑定二维码/查询绑定信息) 
- activity_client: xpd_bind_qr(roleParam 签发 livelink 绑定链接, 微信扫码进小程序绑定)
  + xpd_bind_info(bindInfo 查询绑定状态/角色/平台), gameRole 非 dict 边界防护
- runner/service: 注册 get_xpd_bind_qr / query_xpd_bind_info 任务, 回写
  xpd_game_name / xpd_bind_status
- router: get_xpd_bind_qr 的 url 加入列表接口保留白名单(二维码展示)
- 前端: 和平小店面板新增两个按钮, 二维码列支持 get_xpd_bind_qr 展示/放大
 2026-08-06 17:33:11 +08:00
yml2213 fdc74eba8c feat(douyu): 新增和平小店查询模块(绑定角色/商品列表/点券余额) 
- activity_client: getIframeUrl 签发 code/sig,道聚城 getrole.out/recommend/balance 接口
  (2026-08 起需 isCode=1 + authType=delegate + sAnchorId 才能通过 Livelink 校验)
- 迁移 0016: accounts xpd_* 字段、douyu_config 小店配置(actAlias/actId/rid)、
  douyu_xpd_goods_snapshot 商品快照表
- runner/service/router/schema 注册 query_xpd_role/refresh_xpd_goods/query_xpd_balance
  三个任务,任务结果剥离 role.raw 防 openid 泄露
- 前端: 和平小店路由/菜单/DouyuTasksPage 三态/商品下拉/配置弹窗
 2026-08-06 17:23:59 +08:00
yml2213 8de269f958 增加兑换 2026-07-28 18:12:11 +08:00
yml2213 d7a8666fe4 新增电竞手册独立绑定流程 2026-07-28 17:12:08 +08:00
yml2213 3350b56f5c 优化任务操作台交互体验 2026-07-25 11:21:53 +08:00
yml2213 9471a5b4ff 修复斗鱼绑定主链路：双 actAlias 分工与任务驱动扫码确认 
扫码/确认走活动 alias，角色与换绑最新态优先查 cjm；生成二维码前强制校验换绑冷却，前端以任务结果为单一数据源展示二维码、待确认角色与换绑时间。
 2026-07-24 22:36:25 +08:00
yml2213 62099e8d68 新增斗鱼活动任务模块：绑定、宝典、鱼翅、积分、兑换等功能 
- 新增 activity_client.py：封装斗鱼活动/兑换/充值/送礼接口
- 新增 cookie_utils.py：Cookie 解析与规范化工具
- 新增 douyu_service/douyu_runner：斗鱼任务服务层与批量执行器
- 新增 douyu 路由：任务类型查询、账号列表、配置管理、商品管理、批量任务、WebSocket 日志
- 新增 models/schemas：DouyuTask/DouyuConfig/DouyuGoodsSnapshot 模型，Account 扩展点数/鱼翅/绑定状态等字段
- 新增数据库迁移：斗鱼活动相关表与 accounts 字段补充
- 新增前端 DouyuTasksPage 任务操作台页面
- 兑换商品请求添加 sec-ch-ua 反检测头
- 兑换商品支持最多 8 次重试 + csrf_token 自动刷新
- 注册 douyu:task / douyu:config 权限点
- 侧边栏新增斗鱼分组与任务操作台菜单入口
 2026-07-24 16:11:39 +08:00