hi-server

HI-VPN/hi-server

Fork 0

Commit Graph

Author	SHA1	Message	Date
shanshanzhong147	5b9f384f81	修复(#132 ): 退款幂等校验 + 已退款订单防重新激活 Build docker and publish / build (20.15.1) (push) Failing after 21m4s Details Build docker and publish / build (20.15.1) (pull_request) Failing after 21m47s Details P01：refundOrderLogic.RefundOrder 在事务内 FOR UPDATE 后、lockCommissionSource 前新增 333 退款日志扫描，命中即返回 OrderAlreadyRefunded(61006)，不再写日志/扣 commission/ 改 order.status。 P02：堵住已退款订单状态被回退入口 - queue/logic/order/stuckOrderRecoveryLogic.go：批扫 status=6 时新增 333 日志守卫，已退款订单不再被重置为 5 + 重新入队 activate（HIF-131 trace 中订单 53647 被刷回 5 的真凶） - queue/logic/order/activateOrderLogic.go：releaseClaim 同步加守卫做防御性兜底新增 internal/model/log/refund.go 共享 helper HasRefundCommissionLog： type=33 + content LIKE 走索引粗筛，再 JSON 反序列化确认 content.type==333 AND content.order_no==orderNo，防 LIKE 子串误判。测试：单元测试覆盖正常退款 / 已有 333 日志拒绝 / 子串误判防御 / 脏 JSON 容错； sqlmock 严格断言命中后事务序列只含 BEGIN/SELECT order FOR UPDATE/SELECT system_logs/ROLLBACK，无任何 commission 写入。不做：calculateCommission、status 枚举拆分、表结构变更、支付通道 notify、用户余额回补。 Co-authored-by: multica-agent <github@multica.ai>	2026-05-31 20:19:35 -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

Author

SHA1

Message

Date

shanshanzhong147

5b9f384f81

修复(#132 ): 退款幂等校验 + 已退款订单防重新激活

Build docker and publish / build (20.15.1) (push) Failing after 21m4s

Details

Build docker and publish / build (20.15.1) (pull_request) Failing after 21m47s

Details

P01：refundOrderLogic.RefundOrder 在事务内 FOR UPDATE 后、lockCommissionSource 前新增
333 退款日志扫描，命中即返回 OrderAlreadyRefunded(61006)，不再写日志/扣 commission/
改 order.status。

P02：堵住已退款订单状态被回退入口
- queue/logic/order/stuckOrderRecoveryLogic.go：批扫 status=6 时新增 333 日志守卫，
  已退款订单不再被重置为 5 + 重新入队 activate（HIF-131 trace 中订单 53647 被刷回 5
  的真凶）
- queue/logic/order/activateOrderLogic.go：releaseClaim 同步加守卫做防御性兜底

新增 internal/model/log/refund.go 共享 helper HasRefundCommissionLog：
type=33 + content LIKE 走索引粗筛，再 JSON 反序列化确认 content.type==333 AND
content.order_no==orderNo，防 LIKE 子串误判。

测试：单元测试覆盖正常退款 / 已有 333 日志拒绝 / 子串误判防御 / 脏 JSON 容错；
sqlmock 严格断言命中后事务序列只含 BEGIN/SELECT order FOR UPDATE/SELECT
system_logs/ROLLBACK，无任何 commission 写入。

不做：calculateCommission、status 枚举拆分、表结构变更、支付通道 notify、用户余额回补。

Co-authored-by: multica-agent <github@multica.ai>

2026-05-31 20:19:35 -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

2 Commits