fix: type CMPP inbox JSON parameters

2026-08-20 19:04:12 +08:00
parent 99fb346566
commit f4560479d3
3 changed files with 7 additions and 2 deletions
@@ -3812,3 +3812,4 @@ git diff --check
 - Worker累计真实指标4695条显示：预检、模板、消息持久化、风控频次、计费和入队平均约`83.9/74.5/28.3/92.2/25.2/64.7ms`，与上一阶段完整链约24条/秒一致。该证据确认不能把入口吞吐冒充完整处理能力。
 - 普通短短信快路径已改为单个PostgreSQL CTE：使用账号唯一索引读取应用和企业当前状态，在同一快照校验接口、IP白名单及Src_Id，并以请求键`ON CONFLICT DO NOTHING`幂等写Inbox和稳定响应。正常路径不再先执行Prisma应用查询；仅并发唯一键竞争且当前快照看不到胜者时执行一次只读恢复，避免用自更新制造表膨胀。长短信分片状态机保持不变。
 - Inbox Worker领取后改为按本批唯一`applicationId`一次查询应用、企业和白名单，再逐条处理；不做跨批应用状态缓存，领取事务仍不包住风控、计费、Redis或供应商调用。专项SendChain 121项、API全量42套493项、API与前端TypeScript、Vite生产构建、Prisma validate、Gateway全量测试/vet、5份Stream契约、R0/R6/R7/R10、安全/部署门禁和`git diff --check`均通过；R9仍只被HEAD既有`dispatchDueScheduledTasks`哈希漂移阻断，未改写该方法。提交、恢复资产、测试环境发布和100→200→500阶梯结果待后续补记。
+- 主提交`99fb346c125b0f620641562c50ad517a7682a10f`发布到测试环境后，100条/秒首轮2998个请求全部收到业务拒绝且API返回500，立即按停止线终止升档。日志给出PostgreSQL `42P18 could not determine data type of parameter $11`；参数定位为`jsonb_build_object`的多态value位置没有为MessageId/phoneCount声明类型。该轮没有新增Inbox或业务短信，不计容量结果；修复为显式`text/integer`类型后须重新走门禁、提交和发布验证。