# SC202：进行中的请求状态码错误

> SC202（进行中的请求状态码错误）表示收到 SIGTERM 时正在处理的请求结束了，但状态码不是 workload.status。找出状态码被改变的原因。

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

`SC202` 表示一个进行中的请求完成了，但 HTTP 状态码与 `workload.status` 不一致。连接已经正常排空，问题要么是响应在关闭期间变了，要么是配置里期望的状态码本身就不对。

| | |
| --- | --- |
| 诊断码 | `SC202` (FAIL) |
| 阶段 | 进行中请求的响应 |
| CLI 退出码 | 1 |
| 含义 | 收到 SIGTERM 时正在运行的请求完成了，但 HTTP 状态码与 `workload.status` 不同。 |
| 输出信息 | `In-flight request returned HTTP <status>; expected <workload.status>` |
| 首先检查 | 让已经在处理的请求正常完成；关闭期间只拒绝新的工作。 |

## 应该检查什么？

- 不触发关闭，单独运行测试请求，记下它正常返回的状态码。
- 确认 `workload.status` 与这个响应一致。
- 检查关闭用的中间件是否对所有请求都返回 `503`。
- 确保排空期间只拒绝**新**请求。
- 使用 probe 启动确认时，检查工作开始后发生的错误。

```json title="shutdown-check.json"
{
  "workload": {
    "path": "/slow",
    "status": 200,
    "started": { "type": "response-headers" }
  }
}
```

不要只是为了让测试通过就改期望的状态码。期望的状态码应该对应正常运行时成功请求返回的响应。

## 如何确认已修复？

分别在不关闭和关闭期间运行测试请求。只要请求是在 `SIGTERM` 之前开始的，两次响应都应该是同一个成功状态码。

新请求收到 `503` 可能是正确的；区别在于请求是什么时候进入应用的。如果不确定中间件的顺序，在请求开始时把排空状态打到日志里。

## 相关内容

- [`workload` 配置](https://shutdown.jscrate.dev/zh/docs/configuration#workload)
- [只拒绝新流量](https://shutdown.jscrate.dev/zh/docs/guides/readiness-and-draining)
- [SC201：请求被中断](https://shutdown.jscrate.dev/zh/docs/codes/sc201)
- [SC203：响应体错误](https://shutdown.jscrate.dev/zh/docs/codes/sc203)