SC111 表示 shutdown-check 无法证明测试请求正在进行。这种情况下它不会发送 SIGTERM,因为已经完成的请求测不出优雅排空的效果。
| 诊断码 | SC111 FAIL |
|---|---|
| 阶段 | 启动与进行中的工作 |
| CLI 退出码 | 1 |
| 含义 | 发送信号之前,测试请求已经结束,或者始终没有表明自己已开始,因此没有进行中的工作可供排空。 |
| 输出信息 |
|
| 首先检查 | 使用在处理期间保持连接打开的接口,或者使用能报告操作已开始的 probe 启动确认。 |
你用的是哪种启动确认?
使用 response-headers 时,每个请求都必须在响应体还没结束时收到响应头。尽早 flush 响应头,稍后再结束响应体:
response.writeHead(200, { "content-type": "text/plain" });
response.flushHeaders();
setTimeout(() => response.end("work complete\n"), 2000);使用 probe 时,那个单独的路由必须在测试请求的响应结束之前,从 inactiveStatus 变为 activeStatus。
如何修复?
- 按处理函数的响应方式,选择匹配的启动确认(start barrier)。
- 让测试请求的持续时间长于启动和信号投递所需的时间。
- 只有在工作确实需要更长时间才开始时,才调大
started.timeoutMs。 - 并发请求使用
response-headers;probe 只支持一个请求。
响应很快的健康检查路由不适合当测试请求。使用一个可控的慢接口,既能代表真实的工作,又不会修改生产数据。
如何确认已修复?
在时间线中确认以下顺序:
work request sent
work confirmed active
signal sent如果 work request finished 出现在 work confirmed active 之前,说明路由仍然太快,或者启动确认观察的状态不对。