False mid-stream drop detection on complete responses
NousResearch/hermes-agent · cluster 94614
Data as of
Nothing open on GitHub. Fix merged in #100515. Check it covers your case.
The short answer
- Known?
- Yes. 6 related items grouped here, 1 issue already closed.
- Fix event
- A fix was merged to main in PR #100515. Check it covers your case. No release data is tracked.
- Tracker
- The maintainers' tracker marks this
unresolved. That is separate from the fix event. - Still open
- Nothing open on GitHub.
These issues and fixes address a recurring bug where fully complete streaming responses are incorrectly identified as mid-stream drops. Multiple fixes target the logic responsible for reading completion markers and finish reasons across different stream states and backends.
Open issues0
Open PRs0
Fixes on record
-
#100515 fix(streaming): complete Portal/vLLM streams no longer misread as mid-stream drops (#90848, #91373; salvages #91189, #91376, #96333)
files:
agent/chat_completion_helpers.py,contributors/emails/[redacted:email],hermes_cli/proxy/server.py,hermes_cli/proxy/sse_done.py,tests/hermes_cli/test_proxy.py,tests/hermes_cli/test_sse_done.py,tests/run_agent/test_partial_stream_finish_reason.py -
#100534 fix(streaming): superseded streams keep their completion marker — no more false drops (#94614, salvage #94625)
files:
agent/chat_completion_helpers.py,tests/run_agent/test_partial_stream_finish_reason.py
3 PRs closed without merging
From the close comments: duplicate 1 · merged via another change 1 · other 1
-
#94624 fix(streaming): stop complete responses from being retried as stream drops · other →
622883b,#100534,#94625 -
#94625 fix(agent): accept marker-only finish_reason chunks after stream supersession · merged via another change →
622883b,#100534,#91189,#100515 -
#99344 fix(agent): harvest finish_reason before the SSE guard can continue past it · duplicate →
#96333
Closed issues · 1
- Closed#94614[Bug]: Hermes intermittently reports a client-side mid-stream drop on responses that are in fact complete.
How this cluster was grouped
-
Link evidence (
structural links throughout): every member is connected by structural evidence: shared changed files, or a closing/superseded reference. -
Pairwise link density
0.33: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36.1.00means every pair is linked.
Pick up a Lab task
Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.
Open the Lab