yml2213
6e729e7a80
时间线从此覆盖**全部**业务事实，`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` 旧凭据列。
93 lines
2.6 KiB
Python
93 lines
2.6 KiB
Python
"""自动化调度：作业注册、调度线程与各作业实现。
|
|
|
|
登记作业请放在 ``register_default_jobs()``，由 ``main.py`` 在启动时调用一次，
|
|
避免 import 顺序影响注册结果。
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
from .jobs.ck_health import JOB_KEY as CK_HEALTH_KEY
|
|
from .jobs.ck_health import run_ck_health
|
|
from .jobs.ck_relogin import JOB_KEY as CK_RELOGIN_KEY
|
|
from .jobs.ck_relogin import run_ck_relogin
|
|
from .jobs.douyu_tasks_retention import (
|
|
JOB_KEY as DOUYU_TASKS_RETENTION_KEY,
|
|
)
|
|
from .jobs.douyu_tasks_retention import (
|
|
run_douyu_tasks_retention,
|
|
)
|
|
from .scheduler import (
|
|
JobSpec,
|
|
automation_enabled,
|
|
ensure_jobs,
|
|
register_job,
|
|
registered_jobs,
|
|
reset_registry,
|
|
run_due_jobs,
|
|
run_job_now,
|
|
scheduler_status,
|
|
start_scheduler,
|
|
stop_scheduler,
|
|
)
|
|
|
|
__all__ = [
|
|
"CK_HEALTH_KEY",
|
|
"CK_RELOGIN_KEY",
|
|
"DOUYU_TASKS_RETENTION_KEY",
|
|
"JobSpec",
|
|
"automation_enabled",
|
|
"ensure_jobs",
|
|
"register_default_jobs",
|
|
"register_job",
|
|
"registered_jobs",
|
|
"reset_registry",
|
|
"run_ck_health",
|
|
"run_ck_relogin",
|
|
"run_douyu_tasks_retention",
|
|
"run_due_jobs",
|
|
"run_job_now",
|
|
"scheduler_status",
|
|
"start_scheduler",
|
|
"stop_scheduler",
|
|
]
|
|
|
|
|
|
def register_default_jobs() -> None:
|
|
"""登记内置作业（幂等）。"""
|
|
register_job(
|
|
JobSpec(
|
|
key=DOUYU_TASKS_RETENTION_KEY,
|
|
title="任务日志清理",
|
|
# 一天一次足够：这是**清理**，不是业务；跑太勤只是白扫索引。
|
|
interval_seconds=24 * 3600,
|
|
batch_size=2000,
|
|
concurrency=1,
|
|
run=run_douyu_tasks_retention,
|
|
)
|
|
)
|
|
register_job(
|
|
JobSpec(
|
|
key=CK_RELOGIN_KEY,
|
|
title="CK 自动重登",
|
|
# interval_seconds 同样是「同一行多久重试一次」的兜底（真实节奏由
|
|
# relogin_next_at 的退避表决定）；批次小、跑得慢，单轮 10 条。
|
|
interval_seconds=6 * 3600,
|
|
batch_size=10,
|
|
concurrency=3,
|
|
run=run_ck_relogin,
|
|
)
|
|
)
|
|
register_job(
|
|
JobSpec(
|
|
key=CK_HEALTH_KEY,
|
|
title="CK 自动巡检",
|
|
# interval_seconds = 单账号多久重新检测一次（不是作业周期；
|
|
# 作业每个 tick 都跑）。全库 12,881 条按 5 分钟一轮、单轮 200 条
|
|
# 反推，吞吐 40 条/分钟，够 6 小时内覆盖一遍（规划 §7.3）。
|
|
interval_seconds=6 * 3600,
|
|
batch_size=200,
|
|
concurrency=5,
|
|
run=run_ck_health,
|
|
)
|
|
)
|