线上(测试机)现象:FRIDAY 推 med_emr_info 每小时整点重试,连挂 25 次, 对面收到 http 500 body={"code":90000,"msg":"request entity too large"}。 根因两层: 1. main.ts 从未显式设 body limit → 吃 body-parser 出厂默认 100KB。 实测卡点 102,381B 过 / 103,405B 挂,正好 100KiB。 网关 client_max_body_size 是 50M,不是它拦的(对面收到的是 PAC 的 JSON 封装)。 2. body-parser 的 PayloadTooLargeError 是裸 Error(非 HttpException), 掉进过滤器的 500/90000 分支 → 对面按文档 §9.1 把 9xxxx 当"PAC 内部错误 → 退避重试",于是整点重试永远重试不好,也看不出是自己包太大。 为什么病历先踩到:测试机实测 friday 已入库 payload 单行大小 —— emr 均 1453B / 峰值 2218B,diagnosis 均 1647B(带主诉/检查/处置/医嘱自由文本) appointment、encounter 均 405B 接入文档 §10 只约束"≤500 条/请求",没约束字节:500 条病历 ≈ 710KB,超默认值 7 倍; 连 405B 的预约行 500 条(≈198KB)也超 —— 雷对所有表都埋着,病历只是先踩到。 改动: - main.ts: useBodyParser 显式设 10MB(json + urlencoded)。取 10MB 是因为它给 500 条病历留了十几倍余量,又远低于网关 50M —— 不把拦截点推到网关(那层返 HTML 413, 对面更难排查)。rawBody 仍由 create 选项保留,不影响 HMAC 验签。 - all-exceptions.filter.ts: 识别 PayloadTooLargeError(type=entity.too.large, 辅以 413 兜底)→ 归 10002 + HTTP 200,回执带上限与建议批量,且不上报 Sentry (对面发包过大不是 PAC 故障)。口径对齐文档 §9.1「字段校验失败/批量超限 → 修正后重发」。 - channel-push.mdx §10: 补字节上限,并给按表的分批建议(病历 50-100 行 / 结构化 500 行)。 验证(本地起真实服务,真 HMAC 签名): 146B / 300KB / 2MB / 8MB → 全部通过验签进入摄入流水线(证明 rawBody 未被破坏) 11MB → 10002 + HTTP 200,回执可指导动作 636 tests passed,service/web typecheck 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
