fix(stream): preserve Chatflow terminal events and completion

[SamizuHM]

Problem

Chatflow has two application-level terminal events: message_end and workflow_finished. The Dify streaming guide documents message_end followed by workflow_finished, but deployed Dify versions can emit the reverse order.

Before this PR, the Chatflow path stopped as soon as it saw workflow_finished. That drops a later message_end. The first revision of this PR instead stopped at message_end, which would drop workflow_finished in the documented order. Treating either event as an unconditional terminal event is therefore incorrect.

Real-stream observation

A manual probe using this PR JAR against a real Chatflow received 343 Dify events in this order:

workflow_started -> node_started/node_finished -> node_started/node_finished -> node_started/node_finished -> node_started -> message x330 -> node_finished -> node_started/node_finished -> workflow_finished -> message_end

The SDK then invoked onStreamComplete. In this run, workflow_finished was event 342 and message_end was event 343. No Dify error event occurred. The temporary conversation was deleted after the probe.

This is intentionally application-agnostic evidence: no endpoint, credential, answer text, or business-specific behavior is included in this PR.

Solution

• Add an internal stream-line result so the reader can distinguish continue, normal completion, and a Dify error event.
• For Chatflow, dispatch every event first and track message_end and workflow_finished independently for that individual stream.
• Stop local reading only after both Chatflow terminal events have been delivered, regardless of their order.
• If the connection reaches normal EOF before both events arrive, invoke the generic completion callback as a transport-level fallback.
• Do not invoke the completion callback after a Dify error event or a transport failure.
• Wire the generic completion callback into chat, completion, workflow, workflow-event, and both knowledge-pipeline streaming APIs.

Completion contract

Stream outcome	Event callbacks	onStreamComplete
Chatflow receives both terminal events in either order	Both are delivered	Yes, after the second event
Chatflow reaches EOF after only one or neither terminal event	Received events are delivered	Yes, as EOF fallback
Dify sends an error event	onError	No
HTTP or transport failure	onException	No

onStreamComplete only means that the SDK has stopped reading the non-error SSE response. It is not an assertion that a Dify workflow or application-level business operation succeeded.

Tests

Automated tests use in-memory SSE responses and cover:

• Documented order: message_end -> workflow_finished.
• Reverse order: workflow_finished -> message_end.
• EOF before all Chatflow terminal events arrive.
• Dify error events do not produce completion.
• Both knowledge-pipeline streaming entry points invoke completion after workflow_finished.

Command:

mvn -Dtest=ChatflowStreamTerminalEventTest,PipelineStreamCompletionTest test

Result: 6 tests passed.

Scope and non-goals

This PR fixes SDK-level SSE lifecycle handling only. It does not add application business logic, backend persistence, timeout-based ordering assumptions, or a dependency on a particular Dify deployment. EOF remains a fallback rather than the sole application-level completion signal.

Reference: https://docs.dify.ai/en/api-reference/guides/streaming

[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.