test_request_shape_concurrency_cap_and_error_propagation reds at random on an unchanged tree, and the number it reports is the fixture's, not the client's.
tests/tools/test_serve_low_client.py:135 asserts _CompletionHandler.peak <= 2 after run_usage_batch(..., max_concurrency=2). Measured on this tree at f7d517c09, 30 standalone runs of that one case: 1 failure, AssertionError: 3 not less than or equal to 2. A fresh review of #1596 measured the same shape on the unmodified head, 2 failures in 8 runs. tests/CMakeLists.txt:12 registers all of tests/tools as the CTest target test_serve_low_tools, so this reds CI at random, on whatever diff happens to be in flight. It dates to e58858a91 and no issue named it before this one.
The cap it is meant to prove is not the thing it measures. run_usage_batch (tools/bench/run_serve_low.py:335) submits into a ThreadPoolExecutor(max_workers=max_concurrency), so at most two client threads are ever in flight; that guarantee is structural. What peak counts is the number of REQUEST-HANDLER threads inside the fixture's do_POST between its active += 1 and the finally: active -= 1. That window is strictly WIDER than the client's: post_json returns as soon as response.read() has the body and then closes the connection in its own finally, while the handler thread still has to fall out of its try and take the lock again. A worker that gets its response, returns, and submits the next request before the previous handler thread has decremented makes a third handler live, with two client threads. So a peak of 3 is the instrument's own overlap, and reporting it as a breach of the concurrency cap points the reader at run_usage_batch, which is not where the 3 came from.
That is the #1596 review's F4, and the same shape as the general rule that an instrument can inject the defect it reveals.
Deliberately NOT fixed in flow. The repair is a change to what the fixture measures — count the client's in-flight window rather than the handler's, or hold the handler open until the client has read — and either choice changes the guarantee the case asserts. Under AGENTS.md's ## Every change starts from an issue that is the "surprising fix" case, which takes the normal row, spec and fresh-review path rather than riding inside a change about model keys. The lower bound assertGreaterEqual(peak, 2) is the half that actually proves parallelism happened and must survive any repair: a fix that makes the case pass by weakening the bound to <= max_concurrency + 1 measures nothing.
Owning row: BACKEND-BENCH-CUDA-SGLANG-PREFLIGHT, spec cuda-sglang-low-concurrency.md.
test_request_shape_concurrency_cap_and_error_propagationreds at random on an unchanged tree, and the number it reports is the fixture's, not the client's.tests/tools/test_serve_low_client.py:135asserts_CompletionHandler.peak <= 2afterrun_usage_batch(..., max_concurrency=2). Measured on this tree atf7d517c09, 30 standalone runs of that one case: 1 failure,AssertionError: 3 not less than or equal to 2. A fresh review of #1596 measured the same shape on the unmodified head, 2 failures in 8 runs.tests/CMakeLists.txt:12registers all oftests/toolsas the CTest targettest_serve_low_tools, so this reds CI at random, on whatever diff happens to be in flight. It dates toe58858a91and no issue named it before this one.The cap it is meant to prove is not the thing it measures.
run_usage_batch(tools/bench/run_serve_low.py:335) submits into aThreadPoolExecutor(max_workers=max_concurrency), so at most two client threads are ever in flight; that guarantee is structural. Whatpeakcounts is the number of REQUEST-HANDLER threads inside the fixture'sdo_POSTbetween itsactive += 1and thefinally: active -= 1. That window is strictly WIDER than the client's:post_jsonreturns as soon asresponse.read()has the body and then closes the connection in its ownfinally, while the handler thread still has to fall out of itstryand take the lock again. A worker that gets its response, returns, and submits the next request before the previous handler thread has decremented makes a third handler live, with two client threads. So apeakof 3 is the instrument's own overlap, and reporting it as a breach of the concurrency cap points the reader atrun_usage_batch, which is not where the 3 came from.That is the #1596 review's F4, and the same shape as the general rule that an instrument can inject the defect it reveals.
Deliberately NOT fixed in flow. The repair is a change to what the fixture measures — count the client's in-flight window rather than the handler's, or hold the handler open until the client has read — and either choice changes the guarantee the case asserts. Under AGENTS.md's
## Every change starts from an issuethat is the "surprising fix" case, which takes the normal row, spec and fresh-review path rather than riding inside a change about model keys. The lower boundassertGreaterEqual(peak, 2)is the half that actually proves parallelism happened and must survive any repair: a fix that makes the case pass by weakening the bound to<= max_concurrency + 1measures nothing.Owning row:
BACKEND-BENCH-CUDA-SGLANG-PREFLIGHT, speccuda-sglang-low-concurrency.md.