Blizzard
1ee1e87371
fix: 状态/用量回写升级 JetStream 持久 —— 堵住漏账（core NATS fire-and-forget）
问题：usage(计费)/status 回写走 core NATS，网关离线/慢消费者/NATS 抖动期间
dispatcher 发的事件直接丢——任务照跑照烧 token，但这次计费凭空消失（漏账），且零重试零对账。
（对比：提交/审批/入库本就 JetStream 持久，唯独回写是 best-effort。）
修复（照 tasks/approvals 套路）：
- 新增 JetStream 流 SUNDYNIX_USAGE(MaxAge 72h) / SUNDYNIX_STATUS(24h)，捕获 usage.task/status.task。
- PublishUsage/PublishTaskStatus 改 js.Publish（同步等 stream ack）；dispatcher+gateway 启动各自 ensure 流。
- ConsumeUsage/ConsumeTaskStatus 持久消费者 + 显式 ack：落库成功 Ack、失败 Nak 重投自愈、脏数据 Term。
- 幂等保证 at-least-once 安全：usage_event.task_id 唯一 + 门控；SaveUsageEvent 返回 inserted，
仅新插入才累计 Redis 日计数（非幂等旁路，防重投重复累加）；UpdateTaskStatus 按 task_id 覆盖幂等。
live 验证（复现原漏账场景）：提交任务→立刻杀网关→dispatcher 跑完把 usage 发进持久流
（网关离线，usage_event=0 但流积压 1 条=钱没丢）→重启网关→自动补消费：任务 done、
usage_event 补上、公司A 余额扣 0.098、消费者 num_pending/ack_pending 归零。旧设计下这笔会永久丢失。
eval 回写仍 core NATS（仅观测，低价值，暂不改）。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-09 17:07:31 +08:00
..
2026-07-06 12:00:13 +08:00
2026-06-10 11:00:29 +08:00
2026-07-09 17:07:31 +08:00
2026-06-26 15:23:36 +08:00
2026-06-24 11:35:08 +08:00
2026-06-24 11:35:08 +08:00