stacklok / toolhive / 30356783315 / 1
70%
main: 70%

DEFAULT BRANCH: main
Ran
Files 851
Run time 33s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 69.798% (-0.02%) from 69.818%
30356783315.1

push

github

web-flow 
Frame SSE filter-failure errors as SSE events (#6087)

On the text/event-stream path, writeErrorResponse wrote a bare JSON
object straight into the stream body with no "data: " prefix. Per the
WHATWG event-stream grammar that parses as a field named {"jsonrpc",
and an unrecognized field is ignored, so the client never saw the
error at all: it saw a stream that stopped with no response to its
request and hung until its own timeout. That is the worst available
failure mode, because the caller cannot tell it apart from a dead
server.

Emit the error as a "data:" line in place of the frame that failed and
let the loop keep going, so the separator and the trailing
reconciliation frame it exactly as they frame a successfully filtered
frame. Remaining frames are unrelated to the failed one, so continuing
also removes the truncation that the old early return caused by
skipping the reconciliation.

The mid-stream WriteHeader(500) is gone: Flush() has already committed
the headers by then, and text/event-stream carrying a bare JSON body is
unreadable by an SSE client regardless.

writeSSEDataLine's stop return value collapses into err != nil, which
also fixes a latent wart where the caller discarded a non-nil error
whenever stop was false.

This buys framing parity with the success path, not general SSE
correctness. A body carrying more than one event is still mis-framed by
the separator reconciliation, and a body with no trailing blank line
still gets no terminator. Both predate this change, apply equally when
filtering succeeds, and are left alone.

The failure branch is unreachable from any real backend response, so
the tests cover it at the seam rather than through FlushAndFilter: no
test-only injection point was added to production code.

Refs #6037

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

81529 of 116807 relevant lines covered (69.8%)

97.35 hits per line

Source Files on job 30356783315.1