 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
|
0b1fc1dee0
|
feat(events): 补齐资产【出项】—— 开通金额、鱼翅消耗、积分到期（C 最全）
审「哪些操作该进账号生命周期」时发现：**进项有账、出项没账** ——
充值/积分到账都有金额，而开通（花积分）、送礼（花鱼翅）几乎没记，
于是「一共充了多少」算得出来，「花哪儿了」算不出来。
按确认的范围一次做完（应用宝充值**不动** —— 它按游戏角色记账、且未启用）。
## A. 开通类事件补金额
`elite_opened` / `esports_opened` 以前只记「开通后的积分余额」，不记**花了多少**。
现在补 `amount = -(开通前后积分差)`，并用**实测余额差**而不是"开通要多少分"的常量
（活动价、折扣会让实际扣减不同）。任一侧拿不到就不写金额，不编数字。
## B. 鱼翅消耗事件（新 `gold_spent`）
送礼以前只发「积分到账」，**花掉的鱼翅没有任何记录**。现在：
- 送礼**前后各刷一次**鱼翅（原来只在送礼后刷），取**实测余额差**；
- 发 `gold_spent`，`amount` 用负数（与 `exchange` 一致）；
- 余额没减少或拿不到 → **不发**：宁可少一条，也不要记一笔没发生的消耗。
## C. 积分到期（新 `points_expire`）
积分到期是资产真实减少，但**斗鱼不会通知** —— 只在积分查询里给 `willExpireTime`。
所以：
- 新增 `accounts.points_expire_at`（迁移 `0046`），送礼流程学到就写下来；
- 新增作业 `points_expire_check`：扫「已到期且积分未归零」的账号，补写事件并清标记
（不重复记）；积分已为 0 则只清标记、不发事件（避免 `-0` 噪声）。
⚠️ **金额的诚实边界**：到期那一刻**到底扣了多少，我们没亲眼看到**。
所以默认 `confirmed=False`、标题带「（预计）」，记的是「当时余额」这个**预计要归零**的数量，
**不假装它是确认过的扣减**。作业刻意不发网络请求（纯 DB 可跑、不需要 CK），
要变成已确认只能由「到期后重查、真看到余额下降」的调用方补。
## 顺带修掉一个会静默丢事件的坑
同一个任务可能产生**两条事件**（送礼：既「积分到账」又「消耗鱼翅」）。
`source_ref` 是唯一键 —— 共用 `task_ref(task_id)` 会让**后写的那条被静默丢弃**。
已让副事件带后缀（`douyu_task:{id}:gold`），主事件保持原形态（与旧收集器一致）。
有用例专门钉住「一个任务两条事件都不丢」。
## 验证
- `TZ=Asia/Shanghai`：**550 passed / 6 skipped**（+18 条）
- `TZ=UTC`（事件 + 迁移 + 绑定）95 passed；ruff 全绿；前端 build 通过、lint 0 errors
- 真实开发库：迁移 `0046` 已应用；作业烟测 → 扫到 1 个到期账号，
写入「积分到期 -500（预计）」`confirmed=False`，标记被清、重跑不再重复
## 现在的资产流水（斗鱼侧）
| 方向 | 覆盖 |
| --- | --- |
| 进项 | 充值（二维码/供应商/回调三路径去重）✅、积分到账 ✅ |
| 出项 | 兑换 ✅、**开通 ✅（新补金额）**、**送礼鱼翅 ✅（新）**、**积分到期 ✅（新，标预计）** |
| 未动 | 应用宝充值（独立系统、按游戏角色记、当前未启用） |
|
2026-10-04 18:10:46 +08:00 |
|
|
yml2213
|
a64380fbcc
|
feat(account): S6 bind_status 三列拆解 —— 四值枚举、唯一写入口、前端改读账号
`accounts.bind_status` 是个**语义垃圾场**：一个自由文本列，6 个文件、**29 处写入**、
20 多种取值，混了三种东西 —— 真状态（`bind_confirmed`）、动作痕迹（`goods_locked`）、
纯查询痕迹（`points_queried`）。它是**覆盖式**的，所以 `bind_confirmed` 会被之后
任意一次查询盖掉 —— 「这个账号到底绑没绑」根本查不出来。
`esports_bind_status` / `xpd_bind_status` 是同一个病。
## 收敛成四值 + 三列一义
`unknown` / `unbound` / `pending` / `bound`，每个作用域一列：
| 列 | 作用域 |
| --- | --- |
| `accounts.role_bind_status`（**新增**） | 精英宝典角色 |
| `accounts.esports_bind_status`（收敛） | 电竞手册角色 |
| `accounts.xpd_bind_status`（收敛） | 和平小店角色 |
- 新增 `services/account_binding.py`：唯一写入口 `set_bind_status()`，
传旧自由文本直接 `ValueError`（否则垃圾会被写回去）；`map_legacy_bind_status()` 负责旧值映射。
- **29 处自由文本写入全部删除或改走枚举**：真状态走枚举，动作/查询痕迹**不再写状态列**
（动作已由 S5 的直发事件记录，查询痕迹本来就不该是状态）。
- `accounts.bind_status` 保留原值便于比对，**已无任何写入方**，待 S8 drop。
- 一条**源码扫描用例**禁止任何地方再出现 `account.bind_status = "..."` 这类写入。
## 回填不猜（设计文档 §5.5）
只映射**明确陈述了绑定关系**的取值（`bind_confirmed`/`esports_bound`/`xpd_bound` → bound，
`*_qr_*`/`*_ready` → pending，`game_not_bound`/`xpd_not_bound` → unbound），
**其余一律 unknown**。因为列是覆盖式的，「最后一件事是查询」并不代表没绑定。
迁移 SQL 与 Python 映射有一致性用例：**解析迁移源码里的 CASE 逐条比对**
（已反向验证：故意改错一条映射，用例立刻红）。
## ⚠️ 顺带救回一个差点被我自己丢掉的状态
「**电竞手册是否已开通**」以前**只寄生在 `esports_bind_status` 的 `esports_opened`
取值里**（`elite_opened` 有独立布尔列，电竞没有）。归一化会把那个取值抹成 `unknown`
→ **静默丢状态**。所以：
- 新增 `accounts.esports_opened` 布尔列（与 `elite_opened` 对称），开通任务成功时置位；
- 迁移里**必须先 `save_esports_opened()` 再归一化**，顺序用例钉住；
- 详情页「电竞手册」开通状态改读 `esports_opened`。
## 前端不再从任务日志反推账号状态
工作台原来从**当前加载的那一页任务**里挑每个账号最新的一条来推绑定状态
（`latestConfirmBindTaskByAccount` 等）。两个问题：① 支撑任务一旦翻出窗口，
**显示的状态就是错的**；② 这让任务日志变成「账号状态库」，于是它永远不敢清理。
现在状态读账号字段，任务日志只补「扫码流程中的瞬时信息」（如确认前的
`pending_role_name`）。删掉了两个不再需要的派生与对应的 `clearPending` 绕行逻辑。
## 踩到并修掉的东西
- **模型与迁移不一致**：我把模型收窄成 `String(16)`，迁移却留着 `String(32)` ——
测试库按模型建、生产按迁移建，两边列宽不同。已让迁移也收窄，且**收窄必须在
归一化之后**（旧取值最长 19 字符，先收窄会截断成废值）。downgrade 也补齐了反向操作，
已实测 `downgrade -1 && upgrade head` 干净。
- **parity 用例第一版是抄了一份 SQL**（迁移改了用例也不会红，等于没测）——
改成解析迁移源码；后来又因为列已收窄、19 字符的旧值塞不进测试库，
干脆改成源码级解析比对（不造数据）。
## 验证
- `TZ=Asia/Shanghai`：**490 passed / 6 skipped**（S5 后 450 → 净增 40）
- `TZ=UTC`（相关文件）106 passed；迁移链 3 passed；ruff 全绿
- 前端 `tsc -b && vite build` 通过、`npm run lint` **0 errors**
- 真实开发库：迁移重放后三列均为 `varchar(16) NOT NULL DEFAULT 'unknown'`；
12 个账号的旧值 `elite_status_queried`（纯查询痕迹）→ **unknown**（没有猜成 bound）
未做（后续）：S6 的**账号页重构**（列表关键列 / 生命周期主页）保留；
`bind_status` 旧列待 S8 drop；保留策略里「状态派生类查询」现在技术上可下探到 7 天档，
保守起见留待确认（影响的是在用页面显示，不是历史）。
|
2026-10-04 16:28:06 +08:00 |
|
|
yml2213
|
6e729e7a80
|
feat(account): S5 业务事实直发事件 + 删掉收集器 + 任务日志保留策略
时间线从此覆盖**全部**业务事实，`douyu_tasks` 也有了可控的增长边界。
## 一、删掉收集器（它必然漏数据）
`jobs/account_events_collect.py` 连同 `_task_to_event` / `COLLECTED_TASK_TYPES` /
水位线一起删除，迁移 `20261004_0043` 清掉它的作业行。删除理由是实测出来的：
- **靠 allowlist 认业务类型，新增类型就静默丢**：原有名单只有 5 个，
而 `exchange_esports_goods`（电竞兑换）、`exchange_xpd_goods`（和平小店兑换）、
`pay_locked_order`（锁单支付）、`donate_esports_*`（电竞礼物积分）**从来没进过时间线**；
- **「任务 success」≠「业务真的发生了」**（见下）；
- **字段路径靠抽样猜**：二维码充值的 `result` 里根本没有金额，收集器恒写
`amount=None`，`recharge_total` 系统性少计；
- 作业默认 `enabled=False`，生产上一直没跑。
历史**不回填**（既有结论不变）：需要历史走斗鱼侧权威接口
（`query_exchange_records` / `query_xpd_purchase_records` / `query_points` 都是现成任务类型）。
## 二、业务事实直发：命名构造函数
新增 `services/business_events.py`：`record_recharge` / `record_exchange` /
`record_points_credit` / `record_bind`。每类事实的字段、标题、金额符号只定义一次
（与 S4 的 `record_account_action`、`on_ck_verdict` 同一套路）。
**9 处成功点接线**：`exchange_goods` 真兑换分支、`exchange_esports_goods`、
`exchange_xpd_goods`、`pay_locked_order`、`create_gold_qr`（二维码 + 供应商轮询 +
**供应商回调**三条路径）、`donate_elite_gift`、`donate_esports_gift`、
`confirm_bind`、`confirm_esports_bind`。
**只记真实事实**（按你的决定）：`exchange_goods` 里「预约到货 / 已预兑 / 预兑确认」
三条 success 分支**不发事件** —— 它们不消耗积分也没换到东西，旧收集器只按 status
收集，于是每预约一次就生成一条金额为空的 `exchange` 把 `exchange_count` 灌大。
`confirm_bind` 里「检测到账号本来就已绑定」那条也跳过。
## 三、修掉两个真 bug（都是钱账）
1. **到账判据 `!=` → `>`**（`douyu_runner_gold.py`）：余额**下降**也算「鱼翅已到账」。
批内并发（最高 10）时同账号送礼会消耗鱼翅，余额一变就被充值任务读成到账，
**往台账记一笔根本没发生的充值**。
2. **供应商回调晚于 runner 超时**：原来守卫是「任务状态没被改过才更新」，
于是 runner 先判 failed、回调随后说成功的那笔真金白银**永远不进时间线**。
改成按**回调自己的终态**判断，并补发事件。
## 四、发射顺序：一个会静默丢事件的坑
`_mark_task` 内部 `db.commit()`，而 `emit` 用 `db.begin_nested()` **只 RELEASE
SAVEPOINT、不提交外层事务**；runner 的 `finally` 只 `close()`（未提交即回滚）。
所以**在 `_mark_task` 之后发事件会被静默丢弃，且 `emit` 仍返回 True**。
所有接线一律紧贴 `_mark_task(success)` **之前**，并加了源码扫描用例钉住
（已反向验证：故意挪到之后，用例立刻报出 file:line）。
## 五、`douyu_tasks` 保留策略（新增作业，默认关闭）
`jobs/douyu_tasks_retention.py`，两档：
| 档 | 保留 |
| --- | --- |
| 噪声查询（只读看一眼就走，且前端不拿它派生账号状态） | **7 天** |
| 其余一切（业务事实 + 状态派生依赖的查询 + **以后新增的类型**） | **90 天** |
长保留档用 `task_type NOT IN (噪声名单)` 表达 → **新增类型默认长保留**，不会因为
「忘了加名单」被误删（正是收集器翻车的反面）。在途任务（planned/pending/running）
**绝不删**；分批删避免长锁；两个窗口都能在作业 `config` 里改，不必发版。
⚠️ 「前端从任务列表反推账号当前状态」那几类查询（`query_xpd_bind_info` /
`query_esports_game_name` 等）**故意留在长保留档** —— 删早了工作台账号行会变
「未查」，那是把**当前显示**搞坏。根治要靠 §3.6 的状态列拆解（后续阶段）。
作业默认 `enabled=False`，由运维决定何时打开。
## 验证
- `TZ=Asia/Shanghai`：**450 passed / 6 skipped**（S4 后 426 → 净增 24）
- `TZ=UTC`（相关文件）101 passed；ruff check/format 全绿
- 前端 build 通过、lint 0 errors
- 真实开发库：迁移已应用（head `20261004_0043`，孤儿作业行已清）；
保留作业实跑确认「作业行默认关闭、SQL 在 MySQL 上正确、近期行不误删」
- **两处反向验证**：把 `record_bind` 挪到 `_mark_task` 之后 → 顺序用例报红；
修掉 `registered_jobs()` 那个**假绿用例**（它返回 dict，原来的集合推导式
遍历空字典恒成立），并在断言里加了反向确认
未做（后续）：S6 账号页重构 + `bind_status` 三列拆解（做完才能把状态派生类查询
也纳入短保留）、S7 账号检测改账号维度、S8 丢 `login_tasks` 旧凭据列。
|
2026-10-04 16:00:42 +08:00 |
|
|
yml2213
|
09ab80e062
|
完成 Ruff 全量清理
|
2026-08-31 10:55:44 +08:00 |
|
|
yml2213
|
b58c6b4357
|
执行 Ruff 安全自动修复
|
2026-08-31 10:28:14 +08:00 |
|
|
yml2213
|
9a5066cae8
|
type: 收窄斗鱼手册与送礼执行器类型
|
2026-08-30 20:00:09 +08:00 |
|
|
yml2213
|
39b202bc3f
|
refactor(douyu): runner 按功能域拆分 Mixin + 精英手册兑换对齐真机流程 (HAR 审核通过)
拆分: douyu_runner.py (-3186行) → core/bind/manual/gold/donate/goods/xpd 七个
Mixin + 入口聚合类, douyu_batch_registry 供 routers 重导出
精英手册兑换对齐 HAR 抓包 (activity_client +379 行):
- csrf 复用 Cookie 值不再每次 generateCsrf (HAR 实测全程零 csrf 请求),
仅服务端报 csrf 错误时 force_refresh 重试一次
- pay Referer 补 roomId 对齐浏览器
- 新增手册链路接口: elite_user_info/storedetail/pre_exchange check+confirm/
subscribe/batch_limit/赠品兑换/自动转换
- resolve_exchange_plan: 浏览器兑换按钮状态机路由 (normal/subscribe/
pre_exchange/wait/blocked)
- 兑换执行: 人类节奏抖动 → 锁单(火爆重试1次) → 支付分级退避
(频控 30/60/90s 4次上限, 普错 2/5/10/20s 5次上限, 300s 锁单期 15s 余量,
可中断睡眠)
测试: 新增 17 项 (csrf 复用语义/状态机路由/Referer), 全量 94 通过;
未夹带代理改动
|
2026-08-30 11:05:18 +08:00 |
|