Commit Graph

2 Commits

Author SHA1 Message Date
shanshanzhong147 fedad36089 修复(#131): 退款幂等校验 + 已退款订单防重新激活
P01:在 RefundOrder 事务内、lockCommissionSource 之前,先扫描 system_logs
是否已存在该 order_no 的 333 (CommissionTypeRefund) 日志。命中即返回
OrderAlreadyRefunded,不写日志、不动 commission、不动 order.status,
堵住「同一订单被运营人重复退款 → 邀请人佣金被多次扣减」的写入路径。

P02:guard「已退款订单(status=6 + 333 日志)被重新激活」入口。
OrderStatusClaimed(6) 与 orderStatusRefunded(6) 共用同一枚举值,
stuckOrderRecovery 把 10 分钟前的 status=6 当成「卡住的 claim」重置回 5
并重新入队 activate,进而让管理员可二次触发退款。新增 logmodel
HasRefundCommissionLog helper:
- queue/logic/order/stuckOrderRecoveryLogic: 跳过已有 333 日志的订单。
- queue/logic/order/activateOrderLogic.releaseClaim: 同一守卫(防御性)。

新增 internal/model/log/refund.go + 单元测试覆盖 6 个分支(命中、未命中、
子串误判、非法 JSON、空 order_no、DB 错误)。
新增 refundOrderLogic_test.go 覆盖:333 日志已存在 → 直接 rollback、
status==6 短路、status 非 2/5 短路;用 sqlmock 严格断言不再触发 commission
锁/更新/插入。

不做范围:
- 不动 activateOrderLogic.calculateCommission(D03.3 单独立项)。
- 不动 OrderStatusClaimed(6) 与 OrderStatusRefunded 枚举值。
- 不动用户 34456 余额数据(D02 待架构师另行决策)。

Co-authored-by: multica-agent <github@multica.ai>
2026-05-31 20:10:39 -07:00
shanshanzhong147 30221232c9 fix: 修复订单状态机 claim 机制的三个 Bug 并增加 stuck 订单恢复
- 将 OrderStatusClaimed 从 4 改为 6,消除与 OrderStatusFailed 的值冲突
- finalizeCouponAndOrder 改用直接 DB 更新(WHERE status=6→SET status=5),
  绕过 UpdateOrderStatus 的 status<target 守卫,同时用 model.Update 刷新缓存
- releaseClaim 返回 error,调用处检查并记录日志;releaseClaim 失败由 stuck
  recovery 定时任务兜底
- claimAndGetOrder 对 status=claimed 返回可重试错误而非静默跳过;
  ProcessTask 区分 "stuck in claimed" 与 "非 paid 跳过" 两种场景
- 新增 StuckOrderRecoveryLogic:每 10 分钟扫描超时 claimed 订单,
  重置 status=paid 并重新入队 ForthwithActivateOrder,确保不依赖
  asynq 原始重试(可能已超 maxRetry)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: multica-agent <github@multica.ai>
2026-05-25 02:18:19 -07:00