sundynix-agentix

sundynix/sundynix-agentix

Fork 0

Commit Graph

Author	SHA1	Message	Date
Blizzard	f8f7359723	feat(admin): 订阅管理页 + 修「余额列为 NULL 导致充值永不到账」管理端「支付 → 订阅」：套餐配置 + 全平台订阅观测。配置时直接算出「一个周期发几次、合计多少积分」，时长不能被间隔整除时橙字提示到期前会有空档 —— 让人在配的时候就看见后果，而不是上线后才发现只发了一次。顺带修了个真 bug，是拿真库验订阅时撞出来的（本地 42 个租户里 11 个中招）： credit_balance_micro 是后加的列，早于它创建的租户行值为 NULL。而入账语句是「余额 + N」—— SQL 里 NULL + N 仍是 NULL，于是这些租户充值永远不到账：分录照写、余额不动、不报错。这条路径是充值/兑换码/退款/扣费/订阅发放共用的，不是订阅引入的问题。三处修： - 5 处余额增减一律改 coalesce(credit_balance_micro, 0)，新写入自愈； - 启动迁移回填存量 NULL（按账本求和，让「余额 = SUM(ledger)」重新成立）； - 模型只加 default:0，刻意不加 not null —— 存量库有 NULL 行，AutoMigrate 尝试 SET NOT NULL 会直接失败，而且它在回填之前跑，等于把部署搞挂。回归测试先证明能失败（去掉 coalesce → 余额 0）再确认修复。第一版测试因为我给模型加了 not null 而无法造出 NULL，恰好暴露了上面那个部署风险。真库验证：回填后 42 个租户 0 个 NULL；那个"有分录但余额 NULL"的租户余额 2981 = 账本合计 2981.34。管理端页面显示真实订阅（已发放 3 次 = 首笔 + 补发 2 笔）。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 16:28:32 +08:00
Blizzard	80d4aaf4ba	feat(billing): 订阅制后端 —— 手动购买 + 周期发放积分 + 到期失效规格（按需求）：用户扫码买一个订阅周期，有效期内每 N 天发一次积分，到期即失效，不自动续费。N 与每次发放额度都在套餐里配，后台可改。为什么不做自动续费：微信 Native 扫码支付没有代扣能力，真自动续费要走「委托代扣」 ——另一套产品与资质。与其假装有，不如把"到期即失效"这个语义做扎实。两个决定，都写进了代码注释： - 发放语义是累加而非重置。每次刷新写一条 grant 分录、余额累加。重置型（月度配额清零）会让「余额 = SUM(ledger)」这条对账不变量变复杂，且有误清用户自费积分的风险。 - 订阅开通放在 store.MarkOrderPaid 内，而不是各调用方。回调与掉单补偿两条路都经过它，放这一处才没人能漏掉；按 orderID 幂等，重复调用无害。复用而非另造：订阅单与积分包单走同一条支付链路（下单/回调/查单/掉单补偿），只是 kind=sub 且 credits_micro=0——积分不在付款时给，由订阅按周期发。定时器每 10 分钟扫一轮，语义与幂等都在 store.TickSubscription 里，与手动触发共用，不会两处漂移。停机期间欠下的发放会一次性补齐。 8 组测试。其中一条当场抓到真 bug：开通时原本无条件发一笔，同一订单重复开通（回调重推/查单赛跑）会因序号自增绕过幂等索引，白送积分。改为开通也走与定时器同一套排期判断——排期天然幂等。教训：幂等键要锚在业务时间轴上，不能靠自增序号。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 16:11:34 +08:00

Author

SHA1

Message

Date

Blizzard

f8f7359723

feat(admin): 订阅管理页 + 修「余额列为 NULL 导致充值永不到账」

管理端「支付 → 订阅」：套餐配置 + 全平台订阅观测。配置时直接算出「一个周期
发几次、合计多少积分」，时长不能被间隔整除时橙字提示到期前会有空档 —— 让人在
配的时候就看见后果，而不是上线后才发现只发了一次。

顺带修了个真 bug，是拿真库验订阅时撞出来的（本地 42 个租户里 11 个中招）：

  credit_balance_micro 是后加的列，早于它创建的租户行值为 NULL。而入账语句是
  「余额 + N」—— SQL 里 NULL + N 仍是 NULL，于是这些租户**充值永远不到账**：
  分录照写、余额不动、不报错。这条路径是充值/兑换码/退款/扣费/订阅发放共用的，
  不是订阅引入的问题。

三处修：
  - 5 处余额增减一律改 coalesce(credit_balance_micro, 0)，新写入自愈；
  - 启动迁移回填存量 NULL（按账本求和，让「余额 = SUM(ledger)」重新成立）；
  - 模型只加 default:0，**刻意不加 not null** —— 存量库有 NULL 行，AutoMigrate
    尝试 SET NOT NULL 会直接失败，而且它在回填之前跑，等于把部署搞挂。

回归测试先证明能失败（去掉 coalesce → 余额 0）再确认修复。第一版测试因为我给
模型加了 not null 而无法造出 NULL，恰好暴露了上面那个部署风险。

真库验证：回填后 42 个租户 0 个 NULL；那个"有分录但余额 NULL"的租户余额
2981 = 账本合计 2981.34。管理端页面显示真实订阅（已发放 3 次 = 首笔 + 补发 2 笔）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-20 16:28:32 +08:00

Blizzard

80d4aaf4ba

feat(billing): 订阅制后端 —— 手动购买 + 周期发放积分 + 到期失效

规格（按需求）：用户扫码买一个订阅周期，有效期内每 N 天发一次积分，到期即失效，
不自动续费。N 与每次发放额度都在套餐里配，后台可改。

为什么不做自动续费：微信 Native 扫码支付没有代扣能力，真自动续费要走「委托代扣」
——另一套产品与资质。与其假装有，不如把"到期即失效"这个语义做扎实。

两个决定，都写进了代码注释：
- **发放语义是累加而非重置**。每次刷新写一条 grant 分录、余额累加。重置型
  （月度配额清零）会让「余额 = SUM(ledger)」这条对账不变量变复杂，且有误清
  用户自费积分的风险。
- **订阅开通放在 store.MarkOrderPaid 内**，而不是各调用方。回调与掉单补偿两条
  路都经过它，放这一处才没人能漏掉；按 orderID 幂等，重复调用无害。

复用而非另造：订阅单与积分包单走同一条支付链路（下单/回调/查单/掉单补偿），
只是 kind=sub 且 credits_micro=0——积分不在付款时给，由订阅按周期发。

定时器每 10 分钟扫一轮，语义与幂等都在 store.TickSubscription 里，与手动触发
共用，不会两处漂移。停机期间欠下的发放会一次性补齐。

8 组测试。其中一条当场抓到真 bug：开通时原本无条件发一笔，同一订单重复开通
（回调重推/查单赛跑）会因序号自增绕过幂等索引，白送积分。改为开通也走与定时器
同一套排期判断——排期天然幂等。教训：幂等键要锚在业务时间轴上，不能靠自增序号。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-20 16:11:34 +08:00

2 Commits