fix(stream): preserve Chatflow terminal events and completion

[SamizuHM]

Problem

Chatflow streams end with two terminal events, message_end and workflow_finished. Dify's streaming guide says they arrive in that order:

message_end then workflow_finished (both arrive, in that order) for Chatflow apps

The current SDK treats the first terminal event as the end of the stream: it dispatches the event, then breaks out of the read loop and discards the rest of the SSE response. In the documented order that is harmless, because workflow_finished really is the last event. In real deployments the order is not guaranteed. When a Dify server sends workflow_finished first and message_end second, the SDK stops at workflow_finished and silently drops message_end.

Chatflow 流以 message_end 和 workflow_finished 两个终止事件结尾。Dify 官方文档定义它们的到达顺序为：先 message_end，后 workflow_finished。

当前 SDK 把遇到的第一个终止事件当作流的终点：分发该事件后立刻跳出读取循环，丢弃 SSE 响应中剩余的内容。在文档顺序下这没有问题，因为 workflow_finished 确实是最后一个事件；但真实部署不保证顺序。当 Dify 服务器先发 workflow_finished、再发 message_end 时，SDK 会在 workflow_finished 处停止读取，message_end 被静默丢弃。

Why the code ended up this way

This is not a freshly invented design decision; it reflects three rounds of changes in this repo, none of which solved the underlying order problem:

• 使用chatflow流式输出执行完之后socket的没有关闭，导致报错 #128 added “stop reading and close the connection on a terminal event” to make socket cleanup deterministic.
• fix: ensure message_end is received in Chatflow mode #140 observed that stopping at workflow_finished loses message_end in some deployments, and removed workflow_finished from the terminal set so reading continues until message_end.
• refactor(dify): 优化流式响应处理逻辑 #161 parameterized terminal events per app type and put Chatflow back on WORKFLOW_TERMINAL_EVENTS (stop at workflow_finished), which restored the documented-order behavior but re-introduced the loss of message_end in reverse-order deployments.

Each iteration chose one event as the single boundary, so each iteration is wrong for the other order. The two events are both terminal and their order is environmental, not contractual. Building the read loop around “stop at the first terminal event” cannot work for both orderings.

现状不是一次性的设计决策，而是本仓库三轮改动叠加的结果，没有一轮真正解决顺序问题：

• 使用chatflow流式输出执行完之后socket的没有关闭，导致报错 #128 引入“遇到终止事件即停止读取并关闭连接”，让 socket 清理行为确定。
• fix: ensure message_end is received in Chatflow mode #140 观察到某些部署下在 workflow_finished 停止会丢失 message_end，于是把 workflow_finished 从终止事件集合中移除，继续读到 message_end。
• refactor(dify): 优化流式响应处理逻辑 #161 按应用类型参数化终止事件，把 Chatflow 重新放回 WORKFLOW_TERMINAL_EVENTS（在 workflow_finished 停止），恢复了文档顺序下的行为，但重新引入了反序部署下 message_end 丢失的问题。

每一轮都只挑一个事件作为边界，所以每一轮在另一种顺序下都是错的。这两个事件都是终止事件，而它们的顺序取决于环境、不构成协议契约。把读取循环建立在“遇到第一个终止事件就停”之上，无法同时兼容两种顺序。

Real-stream observation

A probe against a real Chatflow produced 343 events ending with:

... -> workflow_finished (event 342) -> message_end (event 343)

The reverse of the documented order. With the current code, event 343 is never read.

对真实 Chatflow 做了一次探针，收到 343 个事件，结尾为：

... -> workflow_finished（第 342 个）-> message_end（第 343 个）

与文档顺序相反。在当前代码下，第 343 个事件永远不会被读取。

Solution

• Make the Chatflow read loop order-independent: track message_end and workflow_finished per stream, and stop reading only after both have been dispatched. If the connection reaches EOF first, EOF ends the read normally.

• Separate error handling from normal completion: a Dify error event or transport failure ends the stream through onError / onException and does not invoke the normal completion callback.

• Wire the normal completion callback into the other streaming entry points (chat, completion, workflow, workflow events, knowledge pipeline) so all streams share the same lifecycle contract.

• 让 Chatflow 读取循环与事件顺序无关：按流分别跟踪 message_end 与 workflow_finished，两个事件都分发后才停止读取；若连接先到达 EOF，则以 EOF 正常结束读取。

• 把错误处理与正常完成分开：Dify error 事件或传输层异常通过 onError / onException 结束流，不触发正常完成回调。

• 把正常完成回调接入其余流式入口（chat、completion、workflow、workflow events、knowledge pipeline），让所有流共享同一生命周期契约。

Behavior after this change

Stream outcome	Event callbacks	onStreamComplete
Chatflow, both terminal events, any order	both delivered	yes
Chatflow, one terminal event, then EOF	delivered event is dispatched	yes, EOF fallback
Dify error event	onError	no
transport failure	onException	no

onStreamComplete means the SDK has finished reading a non-error response; it does not assert that the business operation succeeded.

流结果	事件回调	onStreamComplete
Chatflow 两个终止事件都到达（任意顺序）	两者都交付	是
Chatflow 只到其中一个终止事件，随后 EOF	已到达的事件照常分发	是，EOF 兜底
Dify error 事件	onError	否
传输层异常	onException	否

onStreamComplete 表示 SDK 已读完非错误响应，不代表业务操作成功。

Tests

In-memory SSE tests cover documented order, reverse order, EOF before both terminal events, error events not triggering completion, and completion on the remaining streaming entry points. All pass with mvn -Dtest=ChatflowStreamTerminalEventTest,PipelineStreamCompletionTest,WorkflowEventsStreamCompletionTest test.

内存 SSE 测试覆盖文档顺序、反序、两个终止事件到达前 EOF、error 事件不触发完成，以及其余流式入口的正常完成回调。mvn -Dtest=ChatflowStreamTerminalEventTest,PipelineStreamCompletionTest,WorkflowEventsStreamCompletionTest test 全部通过。

[Copilot]

The job was not started because the account is locked due to a billing issue.

[Copilot]

The job was not started because the account is locked due to a billing issue.