serve: the post-launch smoke test spins forever at 100% CPU if the engine closes the connection mid-response
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
Research direction
Start in apps/rocm/src/providers.rs at read_chunked_sse_body and trace how the smoke test reaches it through serve_summary::run_smoke_test. Reproduce a truncated chunked response using the stream-reader test setup described in the issue, then verify the reader returns an error naming the premature connection close instead of spinning; the regression test should complete promptly.
Written by the indexing model from the issue text.
Description
Current behavior
read_chunked_sse_body (apps/rocm/src/providers.rs) reads each chunk-size line with read_line. At end-of-stream read_line returns Ok(0) and leaves the line empty — and the loop treats an empty line as a blank separator:
if size_line.trim().is_empty() {
continue;
}
So when the connection closes before the terminating 0 chunk, the loop re-reads EOF forever. Each read returns immediately, so this is a busy loop, not a wait: one core at 100%, and the call never returns.
Expected behavior
A connection that closes before the final chunk ends the stream with an error naming what happened.
Steps to reproduce
Serve a chunked streaming response that sends headers and at least one complete chunk, then closes. Reproduced end-to-end over a real TCP socket: provider_stream_chat had not returned after 40 s — longer than the 30 s socket read timeout, which confirms it is spinning rather than waiting for data.
How a user hits it
Correction: an earlier version of this issue said
rocm chathangs. That was wrong —rocm chatand the dash chat use the non-streamingprovider_chat, whose read is already time-limited. The only production caller of the streaming reader is the smoke testrocm serveruns after launching an engine (serve_summary::run_smoke_test), and that only runs when stdout is a terminal.
So the symptom is rocm serve stuck forever on "Running smoke test…" with one core at 100%, if the engine dies, is OOM-killed, or is stopped while it is streaming its first answer. vLLM streams with chunked encoding, which is the path that spins.
Possible solution
Treat Ok(0) from read_line as end-of-stream, distinct from a blank line, and return an error ("connection closed before the final chunk"). The same check belongs anywhere else this reader distinguishes "empty line" from "no more input".
Related
The close-delimited reader in the same file uses ? on ErrorKind::Interrupted instead of retrying, so a single interrupted read ends the stream. Chunked and fixed-length bodies are unaffected because std's read_line/read_exact already retry. Lower reach, because that path only runs when a response has neither chunked encoding nor a Content-Length.
Environment
- Built from
main. Platform-independent.
How it was found
Property-testing the stream readers: re-chunking real fixture bodies at every boundary showed parsing is chunking-invariant (that part holds), and truncating them showed this reader never terminates. The reproducer uses a reader that panics after 10,000 consecutive empty reads, so the test fails immediately instead of hanging.
- Dominant language
- Rust
- Stars
- 41
- Forks
- 10
- Avg merge
- 5d 3h
- Merged PRs (30d)
- 87
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ROCm/rocm-cli
-
bug
Difficulty 2/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Move the remaining `scripts/` tooling to Rust (`cargo xtask` / e2e scenarios)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
examine: lspci cannot name a GPU that pci.ids does not know, though the device id is on the lineOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 5 days
-
✨ enhancement needs-discussion
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
virtio-fs (Linux passthrough): debug log in do_lookup panics the fs worker on non-UTF-8 file namesPossibly taken @zcl-g5 claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
area:docs documentation good first issue priority:low
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day