 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
|
834bfdd1d0
|
feat(account-events): 账号详情页与账号事件历史全链路支持
1. 新增账号事件数据表 AccountEvent 与迁移版本 20261002_0040_account_events，支持审计 Cookie 变更、自动重登、健康检查及任务执行事件；
2. 后端新增 account_events_service 并扩展 /api/accounts 路由，支持事件查询、过滤与上报；
3. 前端新增 AccountDetailPage 账号详情页组件，支持账号元信息展示、事件历史瀑布流与快捷重登操作；
4. 修复 CK 重登与自动化定时任务中事件关联逻辑，补充 test_account_events 单元测试；
5. 新增生产服务器高负载排查分析报告及相关设计文档。
|
2026-10-03 12:58:58 +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
|
7aaaeebe2b
|
fix(automation): 修正调度口径——作业每 5 分钟跑一轮，interval_seconds 只是单行重检间隔
P1a 把两个「间隔」混成了一个：next_run_at 用的是 job.interval_seconds，于是
作业 6 小时才跑一轮、每轮 200 条 = 800 条/天，全库 12,881 条要 16 天才能过
一遍 —— 等于没巡检，与规划里「账号 6 小时内被查一次」的目标差了两个数量级。
按规划原意修正：
- TICK_SECONDS 60 → 300：作业每个 tick（5 分钟）跑一轮；
- next_run_at 改为 finished + TICK_SECONDS，不再用 interval_seconds；
- interval_seconds 只作为「同一行多久重新检测」的选行 cutoff（选行逻辑本来就
是这么用的，无需改）；
- 容量口径随之更新：5 分钟一轮 × 200 条 = 40 条/分钟 ≥ 需要的 36 条/分钟，
冷启动约 5.4 小时覆盖全库，稳态每轮一百多条；
- 前端标签由「巡检周期(小时)」改为「单账号重检间隔(小时)」，说明文案写清
「每 5 分钟跑一轮」，避免运维误以为是作业周期。
同步更新规划文档 §7.2/§7.3（含两个间隔不能混的说明）与附录 C 的三段上线
步骤（立即跑一次 → 每轮 50 观察 → 每轮 200 启用）。
|
2026-10-02 19:54:31 +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 |
|