live-hub-py

Files

T

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

support

test(db): 测试改用真实 MySQL，方言差异不再漏到生产

2026-10-02 21:22:08 +08:00

conftest.py

test(db): 测试改用真实 MySQL，方言差异不再漏到生产

2026-10-02 21:22:08 +08:00

test_account_actions.py

feat(account): 补上改备注接口，remark_changed 事件从此有发射点

2026-10-04 15:21:48 +08:00

test_account_binding.py

fix(account): 补上电竞绑定映射漏掉的 game_not_bound（连生产库才发现的）