feat: aggregate cmpp template mismatch reviews
This commit is contained in:
hectorzhao
@@ -139,11 +139,18 @@
|
||||
7. 若命中审核策略，运营端短信审核通过后进入发送队列，审核页面必须展示进入审核的原因。
|
||||
8. 发送服务按通道组路由、通道限速、企业限速执行提交。
|
||||
9. 平台批量任务只记录客户端创建的发送任务；API 调用和 CMPP 对接发送不进入批量任务。
|
||||
- 运营端和客户端“短信任务进度”只查询 `SmsBatchTask.sourceType=client`。
|
||||
- CMPP/API/通道测试可使用内部批次承载风控、计费、队列、重试和回执关联，但不得出现在客户批量任务列表。
|
||||
- 客户端批量任务列表、详情、短信明细和取消操作必须同时校验当前企业和 `sourceType=client`。
|
||||
10. 所有来源的短信，包括平台批量任务、API 调用、CMPP 对接发送，全部按手机号维度进入短信记录。
|
||||
11. 任务进度、发送详情和短信记录实时或准实时更新。
|
||||
12. 发送入队必须按短信应用的队列等级分流到优先队列或普通队列；同等条件下优先队列消息必须先于普通队列消息被 Send Worker 消费并提交 Gateway。
|
||||
13. 优先队列只能改变待发送消息的调度顺序，不得绕过企业/应用状态、签名模板审核、通道报备、余额/授信、黑名单、风控、通道组路由、通道限速和 Gateway 连接可用性校验。
|
||||
14. 同一队列内部按创建时间、任务顺序和手机号拆分顺序保持 FIFO 或可解释的稳定排序；优先队列插队时必须可在 trace 或任务日志中追踪队列等级和入队时间。
|
||||
12. 企业应用“不符合模板的短信”配置为 `manual_review` 时，合法的 CMPP Submit 在模板不匹配后进入人工审核；配置为 `reject` 时仍直接拒绝并返回 `REJECTD` Deliver Receipt，其他模式不得被人工审核聚合逻辑误接管。
|
||||
13. CMPP 模板不匹配审核支持短窗口内容指纹聚合：只有同一企业应用、同一 CMPP 账号、规范化后内容 SHA-256 完全一致且位于同一时间窗口的短信才能合并为一个审核任务。默认窗口 10 秒，可通过 `CMPP_TEMPLATE_REVIEW_WINDOW_MS` 调整。
|
||||
14. 聚合审核不合并短信记录、计费或回执：每个手机号仍有独立 `SmsMessageRecord/messageId/sequenceId`。审核通过后逐条进入真实路由和上游提交；审核驳回后逐条释放冻结并产生客户侧 `REJECTD` 回执。
|
||||
15. 人工审核只覆盖模板不匹配；签名必须能从短信前缀识别且已审核/报备通过。签名不合法、风控直接拒绝或余额不足不得因内容聚合而绕过。
|
||||
16. 发送入队必须按短信应用的队列等级分流到优先队列或普通队列；同等条件下优先队列消息必须先于普通队列消息被 Send Worker 消费并提交 Gateway。
|
||||
17. 优先队列只能改变待发送消息的调度顺序，不得绕过企业/应用状态、签名模板审核、通道报备、余额/授信、黑名单、风控、通道组路由、通道限速和 Gateway 连接可用性校验。
|
||||
18. 同一队列内部按创建时间、任务顺序和手机号拆分顺序保持 FIFO 或可解释的稳定排序；优先队列插队时必须可在 trace 或任务日志中追踪队列等级和入队时间。
|
||||
|
||||
### 4.6 通道配置与路由
|
||||
|
||||
|
||||
@@ -1008,6 +1008,7 @@
|
||||
- CMPP2.0 和 CMPP3.0 连接分别返回对应版本 ConnectResp，后续 Submit/Deliver 按该 TCP 连接协商版本解包和组包，不发生字段错位。
|
||||
- 密码错误、应用停用、企业停用、短信接口关闭、IP 不在白名单时 connect/login 被拒绝。
|
||||
- submit 被接受后返回 CMPP SubmitResp 成功，并在真实数据库创建 `sourceType=cmpp` 的发送记录，进入真实发送链路。
|
||||
- `sourceType=cmpp` 的内部批次不出现在运营端或客户端“短信任务进度”；客户端不能通过任务 ID 读取该内部批次的详情、短信明细或执行取消。
|
||||
- Submit 应用身份使用 bind 已鉴权账号；`MsgSrc` 使用应用级企业代码并独立校验。企业代码与登录账号不同时仍能正确定位应用，企业代码不匹配时返回失败。
|
||||
- 鉴权失败、IP 白名单不符、手机号等协议参数不合法时返回非零 SubmitResp，且不创建短信记录。
|
||||
- 已鉴权且参数合法的 Submit 必须先返回成功 SubmitResp 和平台 Msg_Id；内容不匹配审核模板、签名/报备未通过、余额不足、应用在 bind 后停用、无可用通道、上游 Submit 最终失败时，均须真实创建短信记录、`SmsReceiptRecord` 和 `CmppDownstreamDelivery`，并向客户下发 `undelivered/REJECTD` Deliver Receipt，不得仅以 SubmitResp 失败替代回执。
|
||||
@@ -1015,6 +1016,36 @@
|
||||
- CMPP 包在进入 handler 前因长度、命令字、读包或 Unpack 失败时，Gateway 记录 `read/unpack packet failed`、远端地址、协议模式、错误类型和原始错误，不得静默断开。
|
||||
- 企业应用列表和连接详情展示真实下游 CMPP 会话：bind 后当前连接数加一，显示客户 IP、企业代码、CMPP 版本、连接建立时间与最后心跳；连接持续未响应 `ACTIVE_TEST` 超过阈值后转为心跳超时/断开，不能继续显示为正常连接。
|
||||
|
||||
### TC-SEND-038 批量任务与 CMPP 内部批次隔离
|
||||
|
||||
- 优先级：P0
|
||||
- 前置条件：同一企业已存在一个客户端批量发送任务，并通过下游 CMPP 提交一条短信。
|
||||
- 步骤：
|
||||
1. 查询运营端短信任务进度。
|
||||
2. 查询该企业的客户端批量任务列表。
|
||||
3. 使用 CMPP 内部批次 ID 请求客户端任务详情、短信明细和取消接口。
|
||||
4. 查询运营端短信记录。
|
||||
- 预期结果：
|
||||
- 两个任务进度列表只返回 `sourceType=client` 的客户端批量任务。
|
||||
- CMPP 内部批次的详情、短信明细和取消请求均返回不可见/不存在，不泄露内部任务。
|
||||
- CMPP 短信仍完整出现在短信记录、提交、回执和账务链路。
|
||||
|
||||
### TC-SEND-039 CMPP 模板不匹配短窗口聚合人工审核
|
||||
|
||||
- 优先级：P0
|
||||
- 前置条件：应用 A 配置 `templateMismatchMode=manual_review`，应用 B 配置 `reject`；两个应用均已配置审核和报备通过的签名、余额和通道组。
|
||||
- 步骤：
|
||||
1. 在 10 秒内用应用 A 的同一 CMPP 账号向不同手机号提交多条规范化后内容完全一致、签名合法但不匹配模板的短信。
|
||||
2. 用应用 A 提交内容不同、账号不同或跨越聚合窗口的短信。
|
||||
3. 用应用 B 提交同样的模板不匹配短信。
|
||||
4. 分别审核通过和驳回应用 A 的聚合任务。
|
||||
- 预期结果：
|
||||
- 应用 A 同账号、同内容指纹、同窗口的短信只创建一个 `sourceType=cmpp_template_mismatch` 审核任务，审核页展示真实聚合号码数。
|
||||
- 不同应用、账号、内容指纹或窗口的短信不合并。
|
||||
- 应用 B 不进入人工审核，继续逐条产生 `REJECTD` Deliver Receipt。
|
||||
- 审核通过后每条成员独立进入路由、提交和计费；审核驳回后每条成员独立释放冻结并向客户下发 `REJECTD`。
|
||||
- 签名无法识别/未报备、风控直接拒绝或余额不足时不进入聚合审核。
|
||||
|
||||
### TC-GW-007 CMPP 客户到上游 SMSC 完整闭环
|
||||
|
||||
- 优先级：P0
|
||||
|
||||
@@ -1600,3 +1600,20 @@ git diff --check
|
||||
- 保留的固定条数均属于明确的近期日志/监控窗口、超时扫描单批、导出保护、单消息重试尝试或唯一候选判定，这些响应不被页面展示为业务总数。
|
||||
- 已执行 API 全量测试（13 suites、122 项通过），及受影响服务定向测试（5 suites、91 项通过）、API build、前端 build 与 `git diff --check`；前端仅有既有 chunk size warning。
|
||||
- 已将 `390b9700` 部署生产，部署前完成 PostgreSQL 和当前发布源码备份，Prisma 确认 27 条 migration 均已应用。`cmpp-api`、`cmpp-gateway`、Nginx、MinIO 均为 active，`12026/17890/8090/3000` 监听、API/Gateway health 和外部 `12026` HTTP 均通过。使用生产平台管理员会话调用真实受保护 API：企业管理返回 105 条未删除企业，企业应用返回 204 条，不再封顶 100。
|
||||
|
||||
## 2026-07-12 客户批量任务与 CMPP 内部批次隔离
|
||||
|
||||
- 短信任务进度的产品口径回归为“客户在客户端提交的批量发送任务”。运营端和客户端任务列表统一强制 `SmsBatchTask.sourceType=client`，不再展示每条 CMPP Submit 创建的 `sourceType=cmpp` 内部批次或通道测试批次。
|
||||
- CMPP 内部批次仍保留在 PostgreSQL，继续承载模板/签名/报备校验、风控、冻结/计费、队列、补发和 Deliver Receipt 关联；所有 CMPP 号码仍进入短信记录。
|
||||
- 客户端任务详情、任务短信明细和取消接口同时校验当前 `tenantId` 和 `sourceType=client`，不能通过内部批次 ID 读取或操作 CMPP 内部任务。
|
||||
- 生产现状只读核对：`sourceType=cmpp` 2 个、`sourceType=admin_channel_test` 1 个、`sourceType=client` 0 个。部署后任务进度应显示 0 个客户批量任务，但不删除现有内部批次数据。
|
||||
- 已执行 `send-chain.service.spec.ts + operations.service.spec.ts`（2 suites、50 项通过）、API 全量测试（13 suites、125 项通过）、API build 和前端 build；前端仅有既有 chunk size warning。按用户要求本轮暂不部署生产。
|
||||
|
||||
## 2026-07-12 CMPP 模板不匹配短窗口聚合审核
|
||||
|
||||
- 只有企业应用配置 `templateMismatchMode=manual_review` 时，CMPP 模板不匹配短信才进入人工审核。`reject` 继续逐条失败并下发 `REJECTD`；其他模式不被聚合逻辑接管。
|
||||
- 新增 `SmsSendTask.sourceType/aggregationKey/contentHash/windowStartedAt/windowEndsAt`，以应用、CMPP 账号、规范化内容 SHA-256 和默认 10 秒窗口生成唯一聚合键。`SmsMessageRecord.reviewTaskId/signatureId` 保留每条成员与审核任务、真实签名的关联。
|
||||
- 聚合前仍校验签名审核/报备、风控直接拒绝和账户余额，并按每条短信独立冻结。审核通过后逐条恢复到各自 `sourceType=cmpp` 内部批次并入队；驳回后逐条释放冻结、写入失败记录并生成客户侧 Deliver Receipt。
|
||||
- 运营端短信审核页新增“审核来源”和“聚合号码数”，区分 CMPP 模板不匹配聚合与普通风控审核。
|
||||
- 聚合窗口关闭前，任务不返回到待审列表且审核接口拒绝提前操作，避免窗口内后到短信加入已完成任务。
|
||||
- Prisma migration：`20260712113000_add_cmpp_review_aggregation`。已执行 API 全量测试、API build、前端 build、Prisma validate 和 `git diff --check`；本轮按用户要求暂不部署生产。
|
||||
|
||||
Reference in New Issue
Block a user