1.7 KiB
1.7 KiB
Context
批量订购逐行调用后台订单创建，并在全部行处理结束后于同一事务保存任务结果和完成审计。当前完成审计以关联订单审计事件数量充当成功行数；该数量会包含失败记录和重试记录，可能大于输入总行数，违反审计表的批量统计约束并回滚任务完成状态。
Goals / Non-Goals
Goals:
- 使任务完成审计使用本次处理结果的业务成功数和失败数。
- 保持任务结果、汇总计数和完成审计在同一事务提交。
Non-Goals:
- 不改变单笔订单、钱包余额不足或重复输入的业务规则。
- 不恢复或重放历史任务；历史数据由维护者按生产运维流程处置。
Decisions
- 以
processRows返回的successCount和failCount作为任务完成审计的唯一批量统计来源。这些值与将写入任务记录的逐行结果来自同一次处理，满足审计表的计数不变量。 - 移除对关联订单审计事件数量的查询。审计事件数量会因失败记录和重试而膨胀，不能表示批量业务成功数。
Risks / Trade-offs
- [历史待处理任务不自动恢复] → 保持现有状态，避免对已扣款订单重复执行；由维护者核对后受控结案。
- [完成审计仍依赖事务写入成功] → 使用与任务结果一致的统计值，消除本次约束失败原因，同时保留既有原子性。
Migration Plan
- 发布 API/Worker 中的修复后二进制，重点更新 Worker。
- 在隔离环境验证部分成功任务返回完成状态与一致计数。
- 生产历史任务由维护者在核对订单和源文件后手工结案；不重投原 Asynq 消息。
- 若发布异常，回滚 Worker 二进制；该修复不含迁移。