fix: improve retry feedback and deletion stability
This commit is contained in:
@@ -291,6 +291,7 @@
|
||||
- 已实现下游投递失败审计与人工重投第一版:运营端后端与页面可分页查看 `CmppDownstreamDelivery` 的 pending/awaiting_ack/failed/unconfirmed/rejected/delivered 记录,支持按状态、类型、应用和关键字筛选,并可对非 `awaiting_ack` 记录执行人工重投,真实调用 Gateway `/downstream/receipt` 或 `/downstream/uplink`。主记录必须分开保存自动重试次数 `retryCount`、人工重投次数 `manualRetryCount` 和最近人工重投时间 `lastRetriedAt`,操作日志保留重投前状态与自动重试次数。
|
||||
- 同一下游投递的人工重投必须使用 `id + status + updatedAt` 条件更新原子认领;认领后先进入 `manual_requeueing`,避免运营并发请求或 Gateway pending 恢复扫描同时双发。调用完成后进入 `awaiting_ack` 或失败状态;进程中断超过默认 2 分钟后自动转回 `pending`,由 Gateway 单一路径恢复投递。阈值可通过 `CMPP_DOWNSTREAM_MANUAL_REQUEUE_STALE_MS` 调整。
|
||||
- 已实现下游投递批量重投第一版:运营端可在当前页勾选多条 `pending/failed` 下游投递记录,调用真实批量接口逐条重投并返回成功/失败汇总,不允许用前端循环假装成功。
|
||||
- 下游人工重投必须提供完整且可见的操作反馈:单条和批量操作均先使用平台确认弹窗明确重复处理风险,确认提交期间禁用重投操作以防重复点击;真实接口返回后继续在弹窗中展示成功、部分成功或失败结果。单条成功须展示当前真实状态和人工重投次数,批量结果须展示总数、成功数、失败数及逐条失败原因;请求异常时必须提醒先核对列表状态和人工重投次数再决定是否重新提交,不能静默刷新或仅依赖页面顶部弱提示。
|
||||
- 下游投递的 `pending` 展示必须结合真实尝试字段:自动与人工次数均为 0 时显示“待首次投递”,`retryCount > 0` 时显示“等待自动重试”,`manualRetryCount > 0` 时显示“人工重投排队中”。人工重投可重置新一轮自动重试预算,但不得把记录伪装成从未投递。
|
||||
- 下游投递不得无限停留在 `pending`:Gateway 对未写出的结果必须返回明确的 `retryable/reasonCode/errorMessage`。状态回执在原消息映射已经丢失且缺少 `submitSequenceId` 时属于不可恢复错误,立即转为 `failed` 并保留失败原因和操作日志;客户端暂时离线属于可恢复错误,按既有重试次数与指数退避处理。所有 pending 从创建时间或最近人工重投时间起最多保留 72 小时,可通过 `CMPP_DOWNSTREAM_PENDING_TIMEOUT_HOURS` 调整,超时后自动终结为 `failed`。
|
||||
- 新产生的客户侧状态回执投递 payload 必须保存短信原始 `cmppSubmitSequenceId`,使 Gateway 重启后仍能结合账号和平台消息 ID 重建与原 `CMPP_SUBMIT_RESP` 一致的非 0 `Msg_Id`;不得用伪造或为 0 的 `Msg_Id` 冒充成功投递。
|
||||
@@ -524,7 +525,9 @@
|
||||
- 引流信息字段库:用于签名/报备资料结构化采集。
|
||||
- 企业应用级黑名单、全局黑名单、敏感词管理必须提供搜索、添加、启停/删除功能;所有操作调用真实后端 API,写入系统日志。
|
||||
- 企业黑名单必须绑定到具体短信应用,支持按企业、应用、手机号、入库原因、状态搜索;发送预览、风控和发送链路只能拦截当前应用的 active 黑名单号码,不得把同企业其他应用的黑名单串用;全局黑名单支持按手机号、原因、状态搜索;敏感词支持按词、分类/级别、状态搜索。
|
||||
- 全局黑名单“入库时间”、敏感词“创建时间”及运营端其他日期时间字段统一显示为北京时间 `YYYY-MM-DD HH:mm:ss`;格式化必须显式使用 `Asia/Shanghai`,不得直接展示 UTC ISO 字符串或依赖访问者设备时区。
|
||||
- 企业模板管理的企业名称、企业应用、模板名称、模板内容必须是互相独立且可组合的服务端查询条件;企业签名管理的企业名称、企业应用、签名名称/用途和引流信息同样独立查询。按引流信息搜索时,以签名为父级、命中的引流信息为子级分组展开。
|
||||
- 企业签名、企业模板和其他删除治理入口成功后必须先展示“删除已完成”、操作单号及幂等重放状态;用户关闭结果弹窗后再刷新父列表,不能因目标卡片提前卸载而丢失成功反馈。
|
||||
- 企业应用管理提供企业名称、企业应用名称和状态三个独立服务端查询条件。企业黑名单搜索区提供企业名称、企业应用、手机号码、入库原因和状态五个独立条件。
|
||||
- 运营端充值记录和短信记录表头统一左对齐。
|
||||
- “引流信息字段库”菜单命名为“报备字段库”,编辑、删除按钮使用通用操作按钮样式。
|
||||
|
||||
Reference in New Issue
Block a user