feat(account): 兑换记录列 + 修掉 source_ref NOT NULL 导致的事件静默丢失
三件事合成一次提交(按反馈不再一改一提交)。 ## ① 账号列表加「兑换记录」列 次数 + 最近一次(商品名 + 日期),填上列表右侧的空档。 数据源是**账号自己的事件流**(`account_events` 的 `exchange`),不是 `douyu_tasks` 的 JSON —— 后者是执行日志,S5 起业务事实已经在事件里了。 性能上刻意**每页只跑两条聚合查询**(不是每行一条 N+1): 一条分组算 `count` + `max(occurred_at)`(走 `(account_id, event_type, occurred_at)` 复合索引),一条用窗口函数 `ROW_NUMBER()` 取每个账号最新那条的商品名。 实测 6 个账号 3 条兑换事件,聚合与「最近」都正确。 「兑换 」前缀在前端剥掉(列头已经叫「兑换记录」,再带前缀是重复)。 ## ② 修掉一个静默丢事件的 bug(排查中发现的) **现象**:开发库上「状态变迁 / 分配 / 标签 / 备注 / CK 清除」这些事件**一条都没有**, 而带幂等键的事件(业务事实、`ck_invalid`、`relogin_*`)照常写入 —— 时间线看起来有数据,只是恰好缺了某一类,**极难发现**。 **根因**:`source_ref` 是**可选**幂等键(模型与迁移文件都是 `nullable=True`, `emit()` 对没有天然幂等键的事件就传 `None`)。但早期那版迁移 (重编号成 `0041` 之前的 `0040`)建的是 **NOT NULL**,而我后来只改了 **迁移文件**、没管**已建好的库** —— Alembic 只记版本号,不会重放已应用的脚本。 `__pycache__` 里那个 `20261002_0040_*.pyc` 就是旧版留下的痕迹。 **为什么静默**:`emit()` 按设计吞掉任何异常(事件是旁路,不能影响主流程), 只记一条 warning,调用方也从不检查返回值。已实测复现: `emit(...)` 返回 `False` + warning,实际落库 `0` 条。 **修法**:迁移 `20261004_0045` 改回可空(`MODIFY`,**唯一索引保留**,幂等, 生产若跑过旧版也一并修好)。修复后实测:`emit` 返回 `True`、落库 1 条。 ## ③ 补一条能防「未来」同类问题的守卫 `tests/test_migrations.py` 原本只比对「表/列/索引在不在」,**不比对可空性**。 已加:迁移建出的列**不允许比模型更严**(模型说可空、库里 NOT NULL)。 只查这个**危险方向**:反方向(模型 NOT NULL、库里允许 NULL)是无害的宽松, 历史遗留里有 28 处,一并报出来只会制造噪声、逼人修没收益的东西。 > 这条守卫**有边界**,已在代码注释与设计文档 §3.5.1 写明: > 它在**全新库**上跑整链,只能防「未来的迁移建错」,**防不了已有库的历史漂移**。 > 已验证:临时禁用 `0045`,该用例仍通过(全新链本来就是对的)。 ## 验证 - `TZ=Asia/Shanghai`:**503 passed / 6 skipped**(+3 条兑换列用例) - `TZ=UTC`(迁移 + 列表相关)45 passed;ruff 全绿;前端 build 通过、lint 0 errors - 真实开发库:迁移已应用(head `20261004_0045`), `source_ref` 现在 `IS_NULLABLE=YES` 且唯一索引仍在; 不带幂等键的事件确实能落库;兑换聚合返回值正确 注:验证时在开发库那个有 CK 的账号上留了 3 条 `exchange` 演示事件 (兔兔白日梦 / 冠军鸡腿 / 烟花),是为了让列有数据可看,随时可删。
This commit is contained in:
@@ -26,7 +26,7 @@ TESTS_DIR = Path(__file__).resolve().parent
|
||||
PROJECT_ROOT = TESTS_DIR.parent
|
||||
VERSIONS_DIR = PROJECT_ROOT / "web" / "backend" / "migrations" / "versions"
|
||||
|
||||
HEAD_REVISION = "20261004_0044"
|
||||
HEAD_REVISION = "20261004_0045"
|
||||
|
||||
# 迁移新增、但不声明在模型里的复合查询索引。
|
||||
EXTRA_INDEXES = (
|
||||
@@ -105,12 +105,32 @@ class TestMigrationSmoke:
|
||||
assert not missing_tables
|
||||
|
||||
all_db_indexes = set()
|
||||
nullability_mismatches: list[str] = []
|
||||
for name, table in model_tables.items():
|
||||
db_columns = {column["name"] for column in inspector.get_columns(name)}
|
||||
db_cols = inspector.get_columns(name)
|
||||
db_columns = {column["name"] for column in db_cols}
|
||||
model_columns = set(table.columns.keys())
|
||||
missing_columns = model_columns - db_columns
|
||||
assert not missing_columns
|
||||
|
||||
# 可空性只查**危险的那个方向**:模型说可空、库里却是 NOT NULL。
|
||||
# 那样带 NULL 的写入会**在运行时静默失败**(`emit()` 按设计吞异常),
|
||||
# 正是 `account_events.source_ref` 那次事故的形态 ——
|
||||
# 只比对「列在不在」是抓不到的。
|
||||
#
|
||||
# 反方向(模型 NOT NULL、库里允许 NULL)是**无害的宽松**:
|
||||
# SQLAlchemy 总会写值,库里宽松一点不会丢数据。历史遗留里有不少,
|
||||
# 一并报出来只会制造噪声、逼人去修没有收益的东西。
|
||||
db_nullable = {c["name"]: c["nullable"] for c in db_cols}
|
||||
for column in table.columns:
|
||||
if column.name not in db_nullable:
|
||||
continue
|
||||
if bool(column.nullable) and not bool(db_nullable[column.name]):
|
||||
nullability_mismatches.append(
|
||||
f"{name}.{column.name}: 模型说可空,"
|
||||
f"但迁移建成了 NOT NULL(带 NULL 的写入会静默丢失)"
|
||||
)
|
||||
|
||||
db_indexes = set()
|
||||
for index in inspector.get_indexes(name):
|
||||
index_name = index["name"]
|
||||
@@ -121,6 +141,11 @@ class TestMigrationSmoke:
|
||||
missing_indexes = model_indexes - db_indexes
|
||||
assert not missing_indexes
|
||||
|
||||
assert not nullability_mismatches, (
|
||||
"迁移建出的列比模型更严(会在运行期静默丢数据):\n"
|
||||
+ "\n".join(nullability_mismatches)
|
||||
)
|
||||
|
||||
# 迁移新增的复合查询索引(不入模型,但应存在)。
|
||||
for index_name in EXTRA_INDEXES:
|
||||
assert index_name in all_db_indexes, f"迁移链未创建索引 {index_name}"
|
||||
|
||||
Reference in New Issue
Block a user