fix: restore channels after gateway restart

2026-08-26 14:04:44 +08:00
parent 8170f727a3
commit b7ae1aa41a
4 changed files with 13 additions and 4 deletions
@@ -7,6 +7,7 @@
 - 数据库由90条推进至94条migration，实际新增Submit结果幂等、入站Inbox、Submit Outbox和上行eventId四条迁移。API、独立Send Worker、Gateway、安全代理、Fail2ban、PostgreSQL、Redis、Nginx均active，API/Gateway/前端健康，Inbox最终无pending/processing，Submit命令Stream为`pending=0/lag=0`。
 - 发布后发现主API回调模式下未显式配置批量开关时，Gateway却默认启用批量回调；批量路由只存在于独立callback进程，导致`gateway.submit.results`一度累积到97条pending。预生产显式设置`GATEWAY_CALLBACK_BATCH_ENABLED=false`并重启Gateway后，PEL按幂等逐条回调从97持续降至0并连续六次保持`pending=0/lag=0`，未手工ACK或删除事件。
 - 最小代码修复将批量回调改为仅在环境变量严格等于`true`时启用，并增加默认关闭单元测试、示例环境和发布门禁说明。全程未进行压力测试，未由测试人员主动发送、补发或重投短信，未修改通道账号、启停状态、企业余额、白名单、临时号段或测试账号；发布窗口存在预生产客户自然流量，均按真实链路处理。多Gateway P2未实施。
+- 回调修复提交`8170f727a3c547e3c51d7308a08680ecac9ae1f0`已推送并热修复到预生产；热修复备份为`/opt/cmpp-platform-backups/releases/20260826T135700CST-before-8170f72-gateway`，包含当前PostgreSQL custom dump、运行源码、系统配置、旧Gateway二进制和部署标记，SHA-256、`pg_restore --list`及tar可读性均通过。热修复后又发现Gateway单独重启会使供应商连接变成`desired=0/connected=0`；在不修改通道配置的前提下按正确顺序重启API后恢复为`9/9`。发布脚本已改为独立callback（如启用）→Gateway→API→Send Worker，并增加顺序门禁，避免后续仅健康接口正常但供应商通道未恢复。

 > 环境命名：`8.160.169.106:12026`（Web/API）和 `8.160.169.106:17890`（CMPP 入站）实例统一定义为“预生产环境”；`100.93.204.60`统一定义为“虚拟机测试环境”或“测试机”。“虚拟机”不得再用于指代预生产。历史记录中涉及这两个实例的验证和部署按其明确IP归属理解；`production-deploy.sh`、`NODE_ENV=production`及正式生产安全/备份规范保留原有技术语义，不代表测试机或预生产为正式生产。