`windows-msvc-vulkan` is red on every open PR: `test_openai_api_server.exe` fail-fasts with `0xC0000409`, and the job has no `main` baseline to bisect against

[localai-bot]

Found while gating #1973
(PR #1977). PRE-EXISTING and not
that row's defect: the same job fails the same way on at least three other open
pull requests with no file in common with it.

The failure

The windows-msvc-vulkan job runs the test binaries through
scripts/build-windows-release.ps1, and it stops at:

D:\a\vllm.cpp\vllm.cpp\build-pr-windows-vulkan\tests\Release\test_openai_api_server.exe exited with status -1073740791

-1073740791 is 0xC0000409, STATUS_STACK_BUFFER_OVERRUN — the MSVC
fail-fast code, which the CRT also raises for __fastfail and for a detected
security-cookie or control-flow violation. It is a CRASH, not a doctest failure:
the log carries no [doctest] summary and no Assertion line for that binary,
so nothing reports WHICH case was running. The last lines before the crash are
ordinary request logs from the chat-completions cases, ending on a
POST /v1/chat/completions body_bytes=420.

Population

Measured on 2026-08-26 by reading the four jobs' logs directly:

PR	job	binary	verdict
#1977	98175568298	test_openai_api_server.exe	-1073740791
#1975	98169254199	test_openai_api_server.exe	same binary, same stop
#1969	98152969359	test_openai_api_server.exe	same binary, same stop
#1967	98144800167	test_openai_api_server.exe	same binary, same stop

Those four pull requests touch the KV-cache interface, the runner, the LTX-2.5
lane and the record surfaces respectively; the intersection of their diffs does
not include src/vllm/entrypoints/. The common factor is the job, not the
change.

Why nobody has a baseline

windows-msvc-cpu and windows-msvc-vulkan are PR-only jobs — they do not run
on main — so there is no green reference commit to bisect against and no
signal that says when this started. That is the second half of the defect: a
job that only ever runs on pull requests turns a repository-wide red into
something every author must independently re-attribute, which is what this
issue exists to stop happening a fifth time.

What is NOT established

No Windows box was available to this session, so nothing here was reproduced
locally. The crashing case is not identified, the first bad commit is not
identified, and no cause is proposed. test_openai_api_server binds an HTTP
server, and this repository already records that httplib's stop() is a no-op
on a never-listened server so SO_REUSEPORT splits the port
(.agents/environment.md) — that is an ADJACENT known shape and is named as a
hypothesis to check first, NOT as an attribution.

Owned by ENG-RELEASE-WINDOWS. NOT FIXED IN FLOW: it needs a Windows host to
reproduce, it is in a server path unrelated to the KV-cache row that found it,
and identifying the crashing case is its own investigation.

[localai-bot]

Both Windows jobs, not just the Vulkan one. On a workflow_dispatch run of row/KV-DSV4-MULTICACHE-W2 at fcd4e171e (run 32975253972), windows-msvc-cpu (job 98198301117) stops on the same binary:

D:\a\vllm.cpp\vllm.cpp\build-pr-windows-cpu\tests\Release\test_openai_api_server.exe exited with status

So the failing thing is test_openai_api_server itself and not the Vulkan half of the build. That narrows it: whatever crashes does not need a Vulkan device or the Vulkan backend to be present.

The title names windows-msvc-vulkan because that is the job the four pull requests in the table were measured on; read it as both windows-msvc-* jobs.

[localai-bot]

Additional evidence, MEASURED 2026-08-26 while resuming the gate of PR #1977, that narrows this without attributing it: the red is not Vulkan-specific.

windows-msvc-cpu job 98246711139, on PR #1977's merged head f2673e253, fails on the SAME binary as the windows-msvc-vulkan logs this issue was filed from:

scripts/build-windows-release.ps1:31
  D:\a\vllm.cpp\vllm.cpp\build-pr-windows-cpu\tests\Release\test_openai_api_server.exe exited with status
##[error]Process completed with exit code 1.

As in the four logs above, there is no [doctest] summary and no assertion line for that binary — the last output before the fail-fast is ordinary chat-completions request logging (chat template kwargs from request may not set 'messages', Unexpected reasoning effort nonesuch, The decoder prompt (length 40) is longer than the maximum model length of 32), all of which are expected negative-path cases that the suite drives deliberately.

So the failing configuration is windows-msvc-* as a pair, not the Vulkan job, and a hypothesis that reaches for the Vulkan backend can be dropped. Still NOT established: no Windows host was available here either, nothing was reproduced locally, the crashing case is not identified, and no first bad commit is identified. This comment adds one observation and no attribution.