fix: improve retry feedback and deletion stability

2026-08-02 20:39:49 +08:00
parent ecc3d7a504
commit 94e997ec4d
9 changed files with 273 additions and 41 deletions
@@ -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 字符串或依赖访问者设备时区。
 - 企业模板管理的企业名称、企业应用、模板名称、模板内容必须是互相独立且可组合的服务端查询条件；企业签名管理的企业名称、企业应用、签名名称/用途和引流信息同样独立查询。按引流信息搜索时，以签名为父级、命中的引流信息为子级分组展开。
+- 企业签名、企业模板和其他删除治理入口成功后必须先展示“删除已完成”、操作单号及幂等重放状态；用户关闭结果弹窗后再刷新父列表，不能因目标卡片提前卸载而丢失成功反馈。
 - 企业应用管理提供企业名称、企业应用名称和状态三个独立服务端查询条件。企业黑名单搜索区提供企业名称、企业应用、手机号码、入库原因和状态五个独立条件。
 - 运营端充值记录和短信记录表头统一左对齐。
 - “引流信息字段库”菜单命名为“报备字段库”，编辑、删除按钮使用通用操作按钮样式。
@@ -1436,7 +1436,8 @@
  1. 进入运营端“下游投递记录”页面。
  2. 分别按状态、投递类型、应用、关键字进行筛选，检查分页。
  3. 打开一条记录详情，核对 payload、重试次数、最后错误和时间字段。
-  4. 对一条 `pending` 或 `failed` 记录执行人工重投。
+  4. 对一条 `pending` 或 `failed` 记录点击人工重投，先取消确认弹窗，确认没有调用重投接口。
+  5. 再次点击重投并确认，观察提交期间按钮状态和接口成功后的结果弹窗；另模拟一次接口异常。
 - 预期结果：
  - 页面列表来自真实 `/api/admin/operations/downstream-deliveries`，不是前端静态数组或本地状态拼装。
  - 详情展示真实 payload、`retryCount/nextRetryAt/deliveredAt/lastError`。
@@ -1444,6 +1445,8 @@
  - 人工重投后 `manualRetryCount` 递增、`lastRetriedAt` 更新，新一轮 `retryCount` 从 0 开始；系统日志保留重投前状态、原自动重试次数和新人工重投次数。
  - 重投后若尚未真正写出，列表显示“人工重投排队中”，不得误显示“待首次投递”；自动失败退避中的 pending 显示“等待自动重试”。
  - `awaiting_ack` 记录在前端不可选且后端拒绝并发重投，不能仅依赖按钮禁用。
+  - 确认弹窗明确展示投递类型、消息 ID 和重复处理风险；取消时不得请求后端，确认提交期间操作按钮禁用并显示处理中状态。
+  - 单条成功弹窗展示真实返回的当前状态和 `manualRetryCount`；接口失败时弹窗展示错误，并提醒先刷新核对人工次数再决定是否重试，不能静默失败或诱导重复提交。

 ### TC-GW-015 下游投递指数退避

@@ -1465,11 +1468,13 @@
 - 步骤：
  1. 在页面勾选多条可重投记录。
  2. 点击“批量重投”。
-  3. 检查后端返回的成功/失败汇总，并刷新列表。
+  3. 在平台确认弹窗中取消一次，确认未调用接口；再次打开并确认，检查提交期间防重复状态。
+  4. 检查后端返回的成功/失败汇总和逐条失败原因，并刷新列表。
 - 预期结果：
  - 页面调用真实 `/api/admin/operations/downstream-deliveries/requeue` 批量接口，不是前端逐条伪造结果。
  - 后端逐条执行真实重投，返回 `total/successCount/failedCount/results`。
  - 成功和失败记录都会保留真实后端状态与错误信息；空选择时接口拒绝执行。
+  - 批量确认弹窗展示所选条数和重复处理风险；结果弹窗始终展示总数、成功数和失败数，部分失败时列出真实 `results[].errorMessage`，全成功时也不能静默关闭或只刷新列表。

 ### TC-GW-017 下游投递告警统一聚合

@@ -3414,6 +3419,8 @@ npm run verify:phase8
 | TC-ADMIN-023 | 准备多个企业产生不同的当日真实消费金额后打开企业列表。 | API 结果按 `todaySpendCents` 降序；相同金额按企业名称和 id 稳定排序；金额来自 PostgreSQL 当日短信记录聚合。 |
 | TC-ADMIN-024 | 准备多个企业应用产生不同的当日真实发送数量后打开企业应用列表。 | API 结果按 `sentToday` 降序；相同数量按应用名称和 id 稳定排序；数量来自 PostgreSQL 当日短信记录聚合。 |
 | TC-ADMIN-025 | 将通道真实成本分别设为 3、3.5、3.456 分并打开通道列表。 | 分别显示 `3.00 分`、`3.50 分`、`3.46 分`；仅改变展示精度，不改写数据库成本及历史提交成本快照。 |
+| TC-ADMIN-026 | 新增全局黑名单和敏感词，后端时间分别使用跨自然日的 UTC 时间；在不同时区浏览器中打开列表。 | “入库时间”和“创建时间”均按 `Asia/Shanghai` 显示为 `YYYY-MM-DD HH:mm:ss`，不出现 ISO `T/Z`，且结果不随浏览器设备时区变化。 |
+| TC-ADMIN-027 | 连续多轮创建无依赖签名并删除；另连续多轮创建、编辑为待审核后再删除，同时存在待审核任务提醒。 | 每轮资格预检、填写原因、确认删除均只调用一次真实删除接口；结果区显示“删除已完成”和操作单号，刷新后签名不再出现；全局审核提醒不得被误判为删除失败。 |

 ### 17.4 Dashboard 指标细化

@@ -3071,3 +3071,30 @@ git diff --check
 - 发布后API和Gateway自本次发布起error级日志均为0，`panic/fatal/unhandled/exception/error`关键字检查无新增异常；120秒内活跃下游客户连接仍为0。未发送、重投或补发真实短信，未修改真实通道账号、密码、启停状态、企业余额或客户连接。
 - 发布后供应商通道现状为3条connected 1/1：`会员营销-铁布衫`、`赛邮行业-王斯评中转`、`赛邮行业-王斯评中转副本`；`会员营销-富泷`持续约90秒为failed 0/1，数据库原因为`authentication / connect response status: auth failed`。保留系统自动重连，未修改其账号、密码或启停状态。
 - 依赖缓解安全门禁通过。npm audit仍报告既有前端2项high（未使用的React Router RSC路径）和API 3项moderate（Prisma工具链）告警，未执行可能引入破坏性升级的`audit fix --force`。
+
+## 2026-08-01 下游人工重投弹窗与结果反馈修复（本地未提交）
+
+- 线上只读诊断确认预生产运行`37ffce40`，单条重投真实逻辑一直是操作前调用浏览器原生`window.confirm`、成功后仅静默刷新列表、失败时仅在页面顶部显示弱提示；`AdminDownstreamDeliveriesPage.tsx`在`RealseV2.0/c0a4317a`至`37ffce40`之间无差异，本次缺少成功反馈不是R0-R11拆文件引入的回归。拆分仅将同一真实POST接口迁入`src/api/admin/operations.api.ts`。
+- 线上`OperationLog`只读记录显示2026-07-31 16:01:55～16:02:41已受理多条真实状态回执人工重投，其中同一记录人工次数达到2，说明静默成功与缺少处理中锁会增加误判和重复操作风险；诊断过程没有新增重投或修改线上业务数据。
+- 运营端下游投递记录页改用平台`Modal`完成单条和批量重投确认，明确展示投递类型、消息ID或所选条数以及客户侧重复处理风险；提交期间确认按钮显示“重投处理中…”且所有重投入口禁用，避免同一页面重复点击。
+- 单条真实接口成功后结果弹窗展示后端返回的当前投递状态和`manualRetryCount`；批量接口结果始终展示`total/successCount/failedCount`，部分或全部失败时列出真实逐条错误。请求异常时弹窗提醒先刷新核对人工次数和系统日志，避免在结果不明确时直接重复提交。
+- 已同步需求文档和`TC-GW-014/TC-GW-016`，覆盖取消不请求、确认弹窗、处理中防重复、单条成功、批量全成功/部分失败、异常结果提示。代码按用户要求仅保留本地，未提交、未推送、未部署；未发送、补发或重投真实短信。
+- 使用Node.js v24.16.0执行前端TypeScript和Vite v8.1.5生产构建通过，2532个模块完成转换；仅保留既有约2.01MB单chunk提示，`git diff --check`通过。应用内浏览器及Chrome均无可复用的本地运营端登录页，遵守验证码边界且避免真实重投，没有为了视觉验收伪造会话或调用写接口；登录后的确认/结果弹窗真实点击验收待后续具备会话时补测。
+
+## 2026-08-02 运营端安全控制时间格式与企业签名删除稳定性回归（本地未提交）
+
+- 全局黑名单“入库时间”和敏感词“创建时间”不再直接输出后端 UTC ISO 字符串，统一复用`formatDateTime`；共享格式化工具显式固定`Asia/Shanghai`并输出`YYYY-MM-DD HH:mm:ss`，避免依赖访问者设备时区。真实数据库全局黑名单时间为 UTC `2026-08-02 09:02:11`，页面显示北京时间`2026-08-02 17:02:11`；敏感词页面显示`2026-08-02 17:02:22`，两处均无`T/Z`。
+- 企业签名删除使用真实 Smoke Test Enterprise / Smoke SMS App 共执行10轮：3轮创建后直接删除、3轮编辑为待审核后删除、2轮成功反馈修复后复测及2轮截图/最终确认。PostgreSQL确认10条测试签名均为`auditStatus=deleted`，`OperationLog`存在10条`governance.delete/signature`记录；每轮刷新后列表均不再返回目标签名，未发生删除失败、重复删除或残留 active 数据。
+- 原“不稳定”现象不是删除事务或幂等链路失败。删除组件成功后立即调用父列表刷新，目标签名卡片被移除时连同弹窗一起卸载，导致已经生成的“删除已完成/操作单号”结果区无法展示；同时`AppShell`存在独立的待审核任务原生 alert，签名编辑进入待审核后可能在时间上干扰操作观感，但本次10轮没有再次触发该提醒。
+- `DeleteRiskAction`现改为删除成功后切换到独立结果视图，明确展示“删除已完成”和操作单号；用户关闭结果弹窗后才通知父列表刷新。修复后直接删除和编辑为待审核后删除均验证结果视图可见，关闭后列表刷新并移除签名。
+- 已同步需求文档和`TC-ADMIN-026/TC-ADMIN-027`。Node.js v24.16.0下前端TypeScript和Vite v8.1.5生产构建通过（2532 modules），删除治理定向测试1 suite / 6 tests通过，`git diff --check`通过，应用内浏览器控制台无相关warning/error。
+- 本轮测试数据使用独立前缀并全部按系统规则逻辑删除；全局黑名单、敏感词和签名仅保留规定的deleted审计历史。未发送、重投或补发短信，未修改企业余额、真实通道账号/密码/状态、Redis Stream或客户连接。修改仅保留本地，未提交、未推送、未部署；原有下游人工重投及其他工作区改动继续保留，不归因于本轮。
+
+## 2026-08-02 下游重投反馈与时间/删除稳定性修复发布前门禁
+
+- 用户明确授权提交、推送并部署当前工作区全部有效代码。发布范围为下游投递单条/批量人工重投确认与结果反馈、提交期间防重复操作、运营端日期时间统一为北京时间，以及删除治理成功结果在父列表刷新前稳定展示；同步包含需求和测试用例文档。
+- 发布前重新执行`git status --short --branch`、完整`git diff`、`git fetch --prune`并分别核对`HEAD`与`origin/main`，二者均为`ecc3d7a5045b7669d102f4c81cd2f011b207b3b5`且无分叉。`RealseV2.0`注解标签仍指向`c0a4317a7ea641bab39294e596f58f859edfca73`，既定代码回滚基线有效。
+- 发布前预生产实际运行`37ffce40b274e218e6e64210ac9f0f4db88106c8`，源码与数据库均为78条migration。API、Gateway、Nginx、PostgreSQL和MinIO为active；Redis实际端口监听且返回`PONG`，`gateway.submit.commands`消费者1、pending=0、lag=0。4条active供应商通道均为connected 1/1，120秒内活跃下游连接为0，API/Gateway近30分钟error级journal均为0。
+- 本地首次Prisma命令命中系统PATH中的旧Node.js并因不支持`??=`退出，未进入schema检查且未产生代码改动；切换至工作区Node.js v24.14.0后，Prisma format、validate、generate和migrate status全部通过，本地数据库schema up to date。
+- Node.js v24.14.0下API全量29 suites / 389 tests全部通过，API TypeScript正式构建、前端TypeScript与Vite v8.1.5生产构建通过（2532 modules）；Gateway`go test ./... -count=1`和`go vet ./...`、19个Node结构门禁、2个Go结构门禁、依赖缓解安全门禁及`git diff --check`全部通过。Jest仅保留既有`--forceExit`开放句柄提示，Vite仅保留既有约2.01MB单chunk提示。
+- `api/tsconfig.build.tsbuildinfo`、根目录`tsconfig.tsbuildinfo`、`outputs/`和空文件`=`继续作为构建缓存或临时产物排除，不提交、不删除、不错误归因。发布和验证过程禁止发送、重投或补发真实短信，禁止修改真实通道账号、密码、启停状态、企业余额或客户连接。