fix: record cmpp business failures with receipts
This commit is contained in:
@@ -1558,3 +1558,11 @@ git diff --check
|
||||
- 已执行:`channels.service.spec.ts`(24 项通过)、`dictionaries.service.spec.ts`(4 项通过)、`operations.service.spec.ts`(12 项通过)、API build、前端 build 与 `git diff --check` 均通过;前端仍仅有既有 chunk size warning。
|
||||
- 已部署生产验证:`cmpp-api`、`cmpp-gateway`、Nginx、MinIO 均为 active,API/Gateway health 均通过。真实认证 API 返回四类待审明细并与总数一致;手机号段第 2 页返回 25 条、总数 516217、`page=2/pageSize=25`,证明页面分页不再依赖 cursor 猜测总页数。
|
||||
- 浏览器自动化在登录页连接阶段超时,未使用 CAPTCHA 绕过或修改生产数据;登录后页面视觉验收需在下一轮以人工登录或可用浏览器会话补充截图。其余项目以源码、真实 API 和构建结果验收,不能将该未完成的视觉截图记录成已完成。
|
||||
|
||||
## 2026-07-11 CMPP 业务失败回执闭环
|
||||
|
||||
- 修复下游 CMPP 入站的审计缺口:客户已完成 bind、账号可识别且手机号参数合法后,NestJS 会先创建真实 `SmsBatchTask`、`SmsApiRequest` 和 `SmsMessageRecord`,再执行模板、签名/报备、风控和余额校验;不再因模板未报备等业务失败而直接丢弃客户 Submit。
|
||||
- 协议、鉴权、源 IP 和手机号参数错误仍由 Gateway/NestJS 返回非零 SubmitResp,且不创建短信记录。其余业务失败返回成功 SubmitResp 与平台 Msg_Id,并创建真实 `SmsReceiptRecord(rawStatus=REJECTD)` 和 `CmppDownstreamDelivery`,客户通过 Deliver Receipt 获得 `undelivered` 结果。
|
||||
- 同一回执策略覆盖最终通道签名报备失败、无可用路由,以及上游 Submit rejected/timeout 在补发耗尽后的终态失败;失败记录、错误码和错误原因均可在运营端真实短信记录链路查询。
|
||||
- Gateway 在客户 Submit 成功并建立 messageId-连接映射后立即冲刷该账号 pending 下游投递,避免 API 先创建失败回执时只能等待周期补投。
|
||||
- 已执行 `npm --prefix api test -- --runInBand send-chain.service.spec.ts`(34 项通过)、`npm --prefix api run build`、`go test ./...`(Gateway 全量通过)。待本轮全量 API/前端构建及生产验证完成后补充最终部署结果。
|
||||
|
||||
Reference in New Issue
Block a user