Express.js 长时重型查询处理中无触发自动重复执行的问题

结合你贴的日志特征，按概率从高到低列可能的触发原因：

1. 反向代理/网关层的空闲超时与自动重试 #

这是和你日志特征匹配度最高的原因：

• 你提供的日志中，两次POST请求的GMT时间差刚好是2分钟（从Thu, 29 Apr 2021 07:02:25 GMT到Thu, 29 Apr 2021 07:04:26 GMT），完全符合Nginx、K8s Ingress、云负载均衡器的默认空闲超时阈值（120s）。
• 这类组件的默认逻辑是：如果上游Node服务在超时时间内没有返回任何响应头/响应体字节，就会判定本次请求挂起，自动向原始请求源重发完全相同的POST请求，且全程透传原请求的Trace ID，这也是你日志里两次请求共用同一个77e53abf-272c-420d-9e82-d59736a2f169追踪ID的核心原因。
• 你的重型查询全程在执行数据库操作，没有主动给客户端返回任何分块响应，会被代理判定为无数据传输的空闲连接，触发超时重试。
• 验证方式：在路由入口收到请求后，立刻通过res.write(' ')发送一个分块响应字节，后续查询过程中每隔30秒再发一个心跳字节，如果重复请求完全消失，就可以确认是代理层的空闲超时触发的重试。

2. 前端请求层的内置超时重试 #

• 日志显示请求来源是本地前端开发服务http://localhost:8085/，如果前端项目引入了Axios-retry、fetch-retry这类请求重试插件，或者内置了请求超时逻辑，默认的2-3分钟超时阈值触发后，会自动重发同参数的POST请求，同样会透传原请求的追踪ID到后端。
• Chrome等现代浏览器对无响应的POST表单请求，也会在2-4分钟的空闲连接阈值下触发自动重发，完全不需要用户手动操作。
• 验证方式：暂时关闭前端的请求重试逻辑，或者在前端发起请求时打印实际发起的请求次数，如果前端日志里能看到两次相同的POST请求记录，就可以确认是前端层触发的重试。

3. Express服务内置超时配置触发的框架级重复执行 #

• 如果Express服务配置了express-timeout-handler这类超时中间件，默认的超时阈值如果设置为2-4分钟，且超时配置里开启了"重新执行路由逻辑"的降级策略，就会在超时触发时重复执行业务查询逻辑，不需要外部请求触发。
• 这种场景下你会观察到Morgan日志的两次请求记录时间差和超时配置完全一致，且中间不会有新的TCP连接建立的日志。
• 验证方式：暂时注释掉Express层所有的超时中间件，观察重复请求是否消失，如果消失就检查超时中间件的配置项，关闭自动重新执行路由的逻辑，改为超时直接返回504错误。

4. TCP链路空闲探测触发的连接重建重试 #

• 当Node服务和客户端/代理之间的TCP连接，在2-3分钟内没有任何应用层数据传输，中间链路的防火墙、NAT网关会自动回收空闲连接，客户端/代理检测到连接失效后，会自动用相同的请求体重发请求。
• 这类重试的特征是两次请求的入参完全一致，Trace ID透传，且时间差刚好匹配NAT网关的默认空闲连接回收阈值（通常是180s，也就是3分钟）。
• 验证方式：在长查询过程中每隔1分钟主动向响应流写入心跳字节，保持TCP连接有数据传输，如果重复请求消失，就说明是中间链路的NAT/防火墙空闲连接回收导致的重发。

补充说明：你观察到的两次查询执行都到达了Morgan日志层，说明重复请求不是数据库客户端、ORM层的内部重试导致的，这类内部重试不会在HTTP访问日志层留下两次请求记录。

内容的提问来源于stack exchange，提问作者Ruben Rosemary