feat: 增强下游重投与签名质量检测
This commit is contained in:
@@ -1917,6 +1917,7 @@
|
||||
- 已按整条级成功形成`delivered`终态后,如果同一提交尝试又收到明确失败回执,平台保留原始回执和分片审计,但不得自动把已送达终态改成失败、重复退款或向客户推送互相矛盾的失败结果;系统按稳定异常键写入`SmsReceiptAnomaly`,重复矛盾回执累加发生次数。
|
||||
- 运营菜单“Gateway提交异常”更名为“网关异常”,原路由保持兼容。页面使用“提交异常”和“回执异常”两个Tab,均查询真实后端和PostgreSQL;每个Tab必须在标题区说明其数据来源、业务含义、不能代表的结论及人工处理注意事项,避免运营人员间隔较久后误判。
|
||||
- “提交异常”展示Gateway消费提交命令连续失败且没有明确供应商提交结果的死信,可在严格确认未被供应商接收后重新入队;“回执异常”展示供应商回执与平台既有终态冲突的结构化异常判定。回执异常详情必须指明真实回执保存在回执记录、原始CMPP报文在通讯交互日志,不得用异常摘要替代原始证据。
|
||||
- “提交异常”的待处理记录允许运营人员标记为“已处理”。操作只将异常状态原子更新为`resolved`并记录处理人、处理时间和操作日志,不删除异常证据、不重新入队、也不发送短信;已进入重新入队流程的记录不得并发标记。
|
||||
|
||||
## 运营端休眠唤醒与会话锁定恢复(2026-08-09)
|
||||
|
||||
@@ -2015,7 +2016,7 @@
|
||||
- 页面模块顺序固定为“签名通道发送质量”在最上方,其后依次为企业、通道热力图。两张热力图按维度行各自独立分页,每页10行;翻动其中一张不得改变另一张页码,30日日期列继续在各自表格内横向滚动。
|
||||
- 两张热力图的日期列从左到右按日期由大到小展示,即从`T-1`依次到`T-30`。行首主信息只展示签名名称;通道热力图保留识别维度所必需的通道名称和运营商标签,企业名称与企业应用名称不在行内常驻,鼠标悬停签名时再展示。每张热力图内部提供独立搜索框,可按企业名称、企业应用名称或签名名称筛选,并在筛选后回到第一页,不影响另一张热力图。
|
||||
- 热力图有真实检测快照的发送量格子悬停文案必须明确区分“提交条数”和“发送成功条数”,同时可补充上游接受条数、成功率和阈值;不得把上游接受或`SubmitResp status=0`写成发送成功。报备前仍显示“不适用”,没有检测快照仍显示当日无快照。
|
||||
- 页面最下方增加“未报备签名”模块,按所选北京时间自然日统计已提交到平台且有签名的真实`SmsMessageRecord`。当短信号码运营商没有匹配到该签名当前可用的运营商级报备成功事实,且也没有仍处于通过状态的历史通道级兼容报备事实时,计入未报备短信;运营商级事实可位于任一未删除通道,历史兼容事实仅用于避免把旧系统真实通过误报为未报备。结果按“签名 × 实际企业应用”聚合业务短信条数,展示签名、企业、企业应用,支持按三者搜索和每页10行独立分页;无签名的异常消息不在该模块伪造成签名。
|
||||
- 页面最下方增加“未报备签名”模块,按所选北京时间自然日统计真实`SmsMessageRecord`中“短信正文以规范`【签名】`开头,但该企业应用的有效签名库中没有同名记录”的业务短信。判定不再依赖通道或运营商报备任务:已有系统签名、仅缺少通道/运营商报备成功事实的短信不进入本模块;无法从正文开头提取规范签名的异常消息也不得伪造成签名。结果按“正文签名 × 实际企业应用”聚合号码级业务短信条数,展示签名、企业、企业应用,支持按三者搜索和每页10行独立分页。
|
||||
- 数据统计菜单改名为“签名质量检测”,并删除企业应用发送排行、通道占比、当天发送量和当天成功率模块。本项删除已确认,不作为后续可选项保留。
|
||||
|
||||
## 通道组按通道筛选(2026-08-09)
|
||||
@@ -2023,3 +2024,12 @@
|
||||
- 运营端“短信通道组管理”在通道组名称条件之外增加“通道”筛选。选定一个通道后,只展示成员配置中真实包含该`channelId`的未删除通道组;与通道组名称同时输入时按两个条件取交集。
|
||||
- 通道选项必须来自真实通道API,不使用静态列表、Mock或localStorage。页面首次加载时通道组与通道两个独立请求并行执行;选项同时展示通道名称和编码,已删除通道明确标记“已删除”。未加入任何通道组的真实通道仍可选择,选中后结果为零而不得隐藏该选项。
|
||||
- 通道选择控件必须为通用下拉可搜索控件,支持按通道名称或编码搜索;“全部通道”表示不按通道限制,点击“重置”必须同时清空通道组名称和通道条件并回到第一页。
|
||||
# 下游投递后台重投任务(2026-08-12)
|
||||
|
||||
1. 运营端“下游投递记录”必须同时保留单条重投、当前页勾选批量重投,并新增“按筛选条件重投”;分页支持每页 `10/25/50` 条,切换后回到第一页并重新查询真实后端。
|
||||
2. 后台任务使用当前企业、应用、投递类型、状态、创建日期和关键词的后端筛选快照,分页不属于任务范围;任务创建时固定 `snapshotAt`,之后产生的记录不得被卷入。
|
||||
3. 第一版只允许 `pending/failed/unconfirmed/rejected`,不支持批量重投客户端已确认的 `delivered`,`awaiting_ack` 不得并发重投。创建前必须真实预检命中、可重投、跳过和状态分布,原因必填。
|
||||
4. 任务按应用分批执行,默认每秒 10 条;单条失败不阻断整批,连续失败达到 10 条或 ACK 超时/拒绝达到安全阈值时自动暂停。客户离线、等待 ACK 属于等待状态,不得误记为跳过。
|
||||
5. 跳过只表示未调用 Gateway,第一版原因包括:状态已变化、已被客户确认、已被其他任务处理、本任务已成功处理、不属于任务快照、应用或投递能力已停用、投递数据不完整、缺少原 Submit 映射。
|
||||
6. 任务必须支持列表、详情、暂停、继续和终止;终止只影响尚未发送的记录。任务项以 `taskId + deliveryId` 幂等,执行前原子认领并复核状态,API 重启后可继续,成功 ACK 的项目不得再次发送。
|
||||
7. 所有创建、暂停、继续、终止和自动暂停均写操作日志;任务使用真实 PostgreSQL、Gateway 和客户 ACK,不得使用 mock、静态数据或 localStorage。
|
||||
|
||||
Reference in New Issue
Block a user