Description
When the REST /chat endpoint receives a prompt with an invalid strategyName, the request fails during prompt/session construction, but the SSE response still ends with a final complete event instead of an error event.
That makes clients interpret the request as successful even though no valid response was produced.
Affected area
internal/server/chat.go
- current upstream I validated locally:
9743e10273c45e1c377c10ec0ffaf0de8fefb3c8 (v1.4.448)
Minimal reproduction
Send a /chat request with a missing strategy name, for example:
{
"prompts": [
{
"userInput": "hello",
"vendor": "TestVendor",
"model": "test-model",
"strategyName": "missing-strategy"
}
]
}
Current behavior
The handler logs an internal error from chatter.Send() but still closes the stream normally and emits:
{"type":"complete","format":"plain","content":""}
with no SSE error event.
Expected behavior
If request assembly fails before a usable response stream is produced, the SSE stream should emit an error event and should not emit a final complete event for that failed prompt.
Why this matters
For SSE clients, complete strongly implies success. In this case the request actually failed, so the endpoint violates its own streaming contract and can cause silent client-side misclassification of failures.
Local validation evidence
I reproduced this locally with a focused regression test:
go test ./internal/server -run 'TestHandleChat_InvalidStrategyEmitsErrorAndSkipsComplete' -v
I have a narrow fix prepared with a regression test if maintainers are open to a PR.
Description
When the REST
/chatendpoint receives a prompt with an invalidstrategyName, the request fails during prompt/session construction, but the SSE response still ends with a finalcompleteevent instead of anerrorevent.That makes clients interpret the request as successful even though no valid response was produced.
Affected area
internal/server/chat.go9743e10273c45e1c377c10ec0ffaf0de8fefb3c8(v1.4.448)Minimal reproduction
Send a
/chatrequest with a missing strategy name, for example:{ "prompts": [ { "userInput": "hello", "vendor": "TestVendor", "model": "test-model", "strategyName": "missing-strategy" } ] }Current behavior
The handler logs an internal error from
chatter.Send()but still closes the stream normally and emits:{"type":"complete","format":"plain","content":""}with no SSE
errorevent.Expected behavior
If request assembly fails before a usable response stream is produced, the SSE stream should emit an
errorevent and should not emit a finalcompleteevent for that failed prompt.Why this matters
For SSE clients,
completestrongly implies success. In this case the request actually failed, so the endpoint violates its own streaming contract and can cause silent client-side misclassification of failures.Local validation evidence
I reproduced this locally with a focused regression test:
I have a narrow fix prepared with a regression test if maintainers are open to a PR.