|
|
3062182417
|
fix(wle): 超时参数真正生效 —— 售后拦截 20s 不重试、表级探测走 querySlow
11-13 09:10 那轮钉钉推送 300s 超时没发出去。除了业务库本身变慢，代码里还有两笔白等：
1. `{ timeoutMs: 240000 }` 是无效参数
cloudDatabase 只读 connectRequestTimeoutMs / requestTimeout。mssql 12.x 上请求级
request.timeout 不生效，超时只能靠池配置级 requestTimeout，而共享池（query()）的
池级超时在 pool 创建时就定死 —— 所以「给足 4 分钟」从来没生效过，实际一路按
60s（普通 query）/ 300s（querySlow）掐断。
→ cloudDatabase 两个查询入口加 warnLegacyTimeoutOption()：再传 timeoutMs 就告警，
不再静默当没看见。
2. 售后拦截子查询：名义 240s → 真 20s，且不重试
两张售后表在 rpt 副本里是堆表，实测 4.5s / 8.5s。原来超时后 query() 还把它当
可重试错误 resetPool + 重查一次，白等 60s（11-13 日志里约 2 分钟）。
改成 querySlow + connectRequestTimeoutMs=20000 + maxAttempts=1：超了就按既有
catch 降级「不剔除」，不为一个补充判据把整批核验拖进超时窗口。
3. 空窗口的表级 MAX(query_time) 探测改走 querySlow（180s，maxAttempts=1）
全表 MAX 实测已跑不进 60s，用共享池等于永远探测不到 → sourceLastUpdate 恒空，
「0 单是没发货还是没同步」又分不清了。探测失败只需退回「不知道」，不值得重试。
顺带修一个时间炸弹测试：用例「窗口 0 行但数据源是新的」硬编码 sourceMaxQueryTime
为 2026-11-02 09:58，而服务层算 ageMinutes 用的是真实时钟（registry.beijingNow）——
隔一天就变成「停更 24h」，该用例在 origin/main 上从 11-03 起一直是红的。
改成相对当前时间。
测试：warehouseLogisticsException 36/36 通过（新增 2 条「超时参数必须真生效」断言）。
|
2026-11-14 09:28:27 +08:00 |
|
