 yml2213
|
4c1aff47da
|
feat(douyu): 高价值套装改用官方 storehome 三态判定
高价值套装的准入判定改为只认官方精英宝典 storehome 里账号级的
status：0=可兑换、1=已达兑换上限，商品缺失/接口异常=unknown。
兑换记录和积分记录只作历史展示，不参与是否拥有的判定。
原来的 high_value_owned（JSON 名单）无法区分「确认可兑换」和
「官方接口没返回商品」，也无法表达部分失败。改为两套独立状态 +
检查时间（迁移 20261106_0065），旧快照保守回填：status 缺失的
一律 unknown，不猜。
CK 判定失效时在数据层作废结论（降为 unknown），不是展示层降级。
官方 status 是账号维度的，但 CK 失效那段时间账号可能被别人手工
登录并兑换（这些号共享给客服），缓存里的「可兑换」就不成立了；
只在展示层降级的话，CK 恢复后那条陈旧的「可换」会重新变绿。
error（查不到）不作废 —— 查不到不等于账号出问题了。
高价值结论有自己的时钟：资料刷新除了看 overview_queried_at，还看
high_value_checked_at。两者会脱钩（商品接口单独失败时资料时间被刷新、
高价值时间停在原地），少了这一条这类账号会永久停在旧结论。作废的
结论按 6 小时慢速重试，但「从来没查到过」不因此重选 —— 那是接口对
该账号稳定失败，每轮都重选只会反复撞墙。
商城商品列表改用精英宝典的 manualID 拉取，不再寄生在电竞手册分支里
（否则没配电竞手册的配置就永远拉不到商城，三态全部停在待确认）。
筛选拆成三类「查不到」：unqueried（未查资料，旧口径不变）、
high_value_never（从未读到商城）、high_value_unknown（查过但结论
未知/过期）。之前第二类无处可寻 —— 它既不满足 unqueried 也不满足
high_value_unknown。
|
2026-11-06 12:25:08 +08:00 |
|
|
yml2213andCursor
|
998998c390
|
feat(automation): 巡检和重登优先保住高价值账号的 CK
价值按套装和积分现算，不看标签。第 1、2 档 6 小时巡检一次，并先占重登名额。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-10-05 17:51:04 +08:00 |
|
|
yml2213
|
9ac98dad89
|
fix(automation): 补全作业改用界面上的「同一账号多久重检」—— 之前那个字段对它无效
用户问「同一账号多久重检是啥意思」，顺着查发现**我的作业没在用它**。
## 「同一账号多久重检」是什么
**每个账号的体检周期**：一个账号这轮被查了，多久之后才重新进入候选。
批量扫描类作业的通用参数，配合另外两个决定"扫不扫得过来"：
需要的能力 = 总账号数 ÷ 重检间隔
实际的能力 = 每轮条数 ÷ 运行间隔
**实际 < 需要 → 永远扫不完**（队列越来越长）。
按这个口径核对「CK 自动巡检」的默认值（生产 14,574 个持有 CK 的账号）：
需要 14,574 ÷ 6 小时 = 2,429 个/小时
实际 200 条 ÷ 5 分钟 = 2,400 个/小时
**几乎精确匹配** —— 那两个默认值是校准过的，不用动。
## 但我的作业读的是 config 里的 refresh_days
于是界面上那个「同一账号多久重检」**对本作业是死的**（改了没反应）——
正是用户上一条批评过的同一类缺陷：「看起来能配、其实配的是不相干的东西」。
我在同一个问题上连着栽了两次（上一次是拿 `interval_seconds` 当调度频率算吞吐）。
改成 `job.interval_seconds`，与其它批量作业**同一套口径**；
默认 7 天（查过的账号 7 天后再查）。config 里的 `refresh_days` 整个去掉。
## 顺带
- 注册处显式写明两个参数：`interval_seconds=7 天`（重检）+ `run_interval_seconds=5 分钟`（调度）
- 用例改名并加注释，钉住"重检间隔必须来自界面那个字段"
## 验证
TZ=Asia/Shanghai **639 passed / 6 skipped**；ruff 全绿；前端 build 通过。
|
2026-10-04 21:33:50 +08:00 |
|
|
yml2213
|
fd578683b6
|
feat(automation): 新增「账号资料定时补全」作业 —— 分批慢跑，不撞风控
## 为什么不能一次性跑全量
生产约 **8,000 个**「CK 有效但没查过」的账号。一次性发起 ≈ **8 万次斗鱼请求**，
很容易触发风控 —— 而风控一旦触发是**所有账号一起受影响**。试水 200 个时
0.65 秒/账号看着很香（全量 86 分钟），但那正是危险的地方：**跑得越快越容易被封**。
## 新作业 `account_overview_refresh`
照「自动巡检」（`ck_health`）那套做，并复用它的两道保护。
| 项 | 默认 | 说明 |
| --- | --- | --- |
| `interval_seconds` | 30 分钟 | 多久一轮 |
| `batch_size` | 30 | 每轮查多少（约 20 秒跑完）|
| `concurrency` | 3 | 并发 |
| `refresh_days` | 7（config 可调）| 查过的多久后再查 |
| `enabled` | **False** | 默认关，由运维手动开 |
按默认值：8,000 个约 **3 天**补完，全程不打满斗鱼接口。
## 两类账号**分开**（用户明确要求）
- **没查过的**（`overview_queried_at IS NULL`）**优先**
- 查过的只在超过 `refresh_days` 后重新入选
否则"周期性刷新老账号"会永远挤掉"从没查过的新账号"。
MySQL 没有 `NULLS FIRST`，用 `ORDER BY overview_queried_at IS NULL DESC` 等价实现。
## 只查有效 CK
`ck_check_status == 'valid'`。失效的查了也是白查（只会多一条失败记录），
交给「CK 检测与重登」处理。另外沿用 `cookie_operable_filter()`（有 CK 且无在途尝试）、
排除人工状态（停用/归档）与「不参与自动化」的账号。
## 风控熔断（沿用巡检口径）
一轮里失败率 > 50%（且样本 ≥ 10）就**自己把自己关掉**，交给人确认。
消息里写明可能原因，否则运维只看到"失败率高"会一头雾水：
失败率过高，已自动关闭作业（大面积失败通常是**被风控**或接口抖动，请先确认再重开）
样本 < 10 不熔断 —— 1 个失败就是 100%，比例没意义。
## 查询记录
每轮都建真实的 `douyu_tasks` 行（payload 标 `source=scheduled_refresh`），
「哪个账号、什么时候、查出来什么」都有据可查，也能在任务列表里
区分「定时巡检」与「人工点查询」。账号上的 `overview_queried_at`
则是"下次该不该再查"的依据。
## 验证
- **镜像库实测**：`本轮查 3 个：成功 3 / 失败 0（剩 7784 个待查）`
- 本地 `TZ=Asia/Shanghai` **632 passed / 6 skipped**；ruff 全绿
- 新增 11 条用例：选择口径（只查有效 CK、没查过优先、refresh_days 可调、
人工状态排除、batch_size 限流）+ 熔断（高失败率关闭、正常不关、小样本不熔断）
+ 一条回归：计数不能走带 LIMIT 的查询（作业第一版就是这么挂的）
|
2026-10-04 21:14:16 +08:00 |
|