问题描述
当前流式聊天 Provider 在处理上游流式响应时,虽然底层解析函数会返回错误,但这些错误没有继续向上层传播,而是在 goroutine 中被直接吞掉。
具体来说:
- 在
decodeStreamContent(...) 中,JSON 解析失败时会正常返回 error
- 但在
Chat() 的流式 goroutine 中,收到这个 error 后只是直接 return
- 同样,
ReadString('\n') 读流失败时也只是直接 return
因此,上层 TUI 最终只能看到输出 channel 被关闭,容易把“异常中断”误判为“正常流结束”。
相关位置
internal/server/infra/provider/chat_provider.go:159
internal/server/infra/provider/chat_provider.go:175
internal/server/infra/provider/chat_provider.go:193
当前行为
当前逻辑大致如下:
而 decodeStreamContent(...) 内部其实已经返回了解析错误:

也就是说:
- 底层有错误
- 但外层没有把错误传出去
- UI 只能看到流结束,无法区分“正常完成”还是“中途失败”
预期行为
流式读取失败或解析失败时,应显式通知上层,而不是仅关闭文本输出 channel。
上层至少应能区分:
- 正常完成
- 上下文取消
- 流式读取失败
- JSON 解析失败
建议方案
将 Chat() 的流式输出从单纯的 chan string 升级为结构化事件,例如:
type StreamEvent struct {
Content string
Err error
Done bool
}
这样 Provider 可以显式发送:
问题描述
当前流式聊天 Provider 在处理上游流式响应时,虽然底层解析函数会返回错误,但这些错误没有继续向上层传播,而是在 goroutine 中被直接吞掉。
具体来说:
decodeStreamContent(...)中,JSON 解析失败时会正常返回 errorChat()的流式 goroutine 中,收到这个 error 后只是直接returnReadString('\n')读流失败时也只是直接return因此,上层 TUI 最终只能看到输出 channel 被关闭,容易把“异常中断”误判为“正常流结束”。
相关位置
internal/server/infra/provider/chat_provider.go:159internal/server/infra/provider/chat_provider.go:175internal/server/infra/provider/chat_provider.go:193当前行为
当前逻辑大致如下:
而 decodeStreamContent(...) 内部其实已经返回了解析错误:
预期行为
流式读取失败或解析失败时,应显式通知上层,而不是仅关闭文本输出 channel。
上层至少应能区分:
建议方案
将 Chat() 的流式输出从单纯的 chan string 升级为结构化事件,例如:
这样 Provider 可以显式发送: