SC203 means the response returned the expected status but did not contain
the text in workload.bodyIncludes. The request ended normally, but the result
does not prove that the expected work completed.
| Code | SC203 FAIL |
|---|---|
| Stage | In-flight responses |
| CLI exit code | 1 |
| What it means | A request that was running when SIGTERM arrived finished, but its body did not contain workload.bodyIncludes. |
| Message |
|
| First thing to check | Check that the handler writes its full response during shutdown, and that bodyIncludes matches what it sends. |
Why does it happen?
- The handler returned an error page with a success status.
- Shutdown skipped part of the operation.
- The response text changed but the config did not.
- The comparison uses different capitalization or whitespace.
- The expected text appears after the 1 MiB response capture limit.
How do I fix it?
Run the route normally and choose a short, stable piece of text that appears only after success:
{
"workload": {
"path": "/reports/export",
"status": 200,
"bodyIncludes": "export complete",
"started": { "type": "probe", "path": "/test/work-active" }
}
}The match is case-sensitive. Avoid IDs, timestamps, or other values that change on every run.
How do I verify the fix?
Inspect the real response body and confirm the marker appears after successful work. The next run should complete with the expected status and no SC203.
If the response is larger than 1 MiB, choose an earlier marker or test the result through a smaller purpose-built endpoint. The captured prefix is the part shutdown-check can inspect.