fix: default gateway callback batching off

2026-08-26 13:59:21 +08:00
parent 4a17df78b8
commit 8170f727a3
5 changed files with 38 additions and 1 deletions
@@ -1,5 +1,13 @@
 # 第一版系统化测试进度

+## 2026-08-26 发送拦截修复与预生产发布
+
+- P0发送拦截修复提交`4a17df78b85f842f724dd0c405febc86f1c34d43`已推送并发布到预生产；部署标记回读一致。发布前有效恢复资产为`/opt/cmpp-platform-backups/releases/20260826T053341Z-before-4a17df7`，PostgreSQL custom dump、运行源码、环境/systemd/Nginx配置、RPM/Python包清单及Fail2ban安装文件清单均纳入`SHA256SUMS`并通过校验，`pg_restore --list`和tar可读性通过。
+- Alibaba Cloud Linux 4系统仓库不提供兼容的Fail2ban包；预生产按Fail2ban官方固定`1.1.0`源码安装，未增加永久第三方软件源。Fail2ban配置测试、服务状态、SSH、Nginx、nftables空封禁集合和安全代理Socket权限均通过。
+- 数据库由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未实施。
+
 > 环境命名：`8.160.169.106:12026`（Web/API）和 `8.160.169.106:17890`（CMPP 入站）实例统一定义为“预生产环境”；`100.93.204.60`统一定义为“虚拟机测试环境”或“测试机”。“虚拟机”不得再用于指代预生产。历史记录中涉及这两个实例的验证和部署按其明确IP归属理解；`production-deploy.sh`、`NODE_ENV=production`及正式生产安全/备份规范保留原有技术语义，不代表测试机或预生产为正式生产。

 ## 2026-08-12 企业签名弹窗、充值回执、通道列表与金额显示优化（已提交、已部署）