# SC111：测试请求始终未处于进行中

> SC111（测试请求始终未处于进行中）表示 SIGTERM 之前，测试请求已经结束，或者始终没有表明自己已开始。改用慢速的流式接口或 probe 启动确认。

Source: https://shutdown.jscrate.dev/zh/docs/codes/sc111
Last updated: 2026-09-23

`SC111` 表示 shutdown-check 无法证明测试请求正在进行。这种情况下它不会发送 `SIGTERM`，因为已经完成的请求测不出优雅排空的效果。

| | |
| --- | --- |
| 诊断码 | `SC111` (FAIL) |
| 阶段 | 启动与进行中的工作 |
| CLI 退出码 | 1 |
| 含义 | 发送信号之前，测试请求已经结束，或者始终没有表明自己已开始，因此没有进行中的工作可供排空。 |
| 输出信息 | `Every work request must remain active after response headers; use a slow streaming test endpoint or a probe barrier with one request`<br>`Work completed before its start probe became active`<br>`Work-start probe did not become HTTP <activeStatus> while work remained active` |
| 首先检查 | 使用在处理期间保持连接打开的接口，或者使用能报告操作已开始的 `probe` 启动确认。 |

## 你用的是哪种启动确认？

使用 `response-headers` 时，每个请求都必须在响应体还没结束时收到响应头。尽早 flush 响应头，稍后再结束响应体：

```js
response.writeHead(200, { "content-type": "text/plain" });
response.flushHeaders();
setTimeout(() => response.end("work complete\n"), 2000);
```

使用 `probe` 时，那个单独的路由必须在测试请求的响应结束之前，从 `inactiveStatus` 变为 `activeStatus`。

## 如何修复？

1. 按处理函数的响应方式，选择匹配的启动确认（start barrier）。
2. 让测试请求的持续时间长于启动和信号投递所需的时间。
3. 只有在工作确实需要更长时间才开始时，才调大 `started.timeoutMs`。
4. 并发请求使用 `response-headers`；probe 只支持一个请求。

响应很快的健康检查路由不适合当测试请求。使用一个可控的慢接口，既能代表真实的工作，又不会修改生产数据。

## 如何确认已修复？

在时间线中确认以下顺序：

```text
work request sent
work confirmed active
signal sent
```

如果 `work request finished` 出现在 `work confirmed active` 之前，说明路由仍然太快，或者启动确认观察的状态不对。

## 相关内容

- [测试进行中的工作](https://shutdown.jscrate.dev/zh/docs/in-flight-work)
- [启动确认配置](https://shutdown.jscrate.dev/zh/docs/configuration#start-barrier)
- [SC110：探测路由一开始就处于活跃状态](https://shutdown.jscrate.dev/zh/docs/codes/sc110)
- [SC112：工作在 SIGTERM 前结束](https://shutdown.jscrate.dev/zh/docs/codes/sc112)