GitHub Repo
Dify Community Reports Node.js SDK Streaming Timeout Failure: Timer Cleared After Stream Is Returned
A Dify community report dated October 31 says the Node.js SDK’s timeout setting may not cover subsequent reads from a streaming response. The author provided an isolated reproduction, but has not confirmed an impact on production deployments; the streaming timeout contract also remains unclear.
A reliability report concerning the streaming lifecycle has surfaced for Dify’s Node.js SDK. An issue published on October 31 says dify-client 3.1.0 may remove timeout protection prematurely after returning a stream object. If response headers have arrived but the body stops transmitting, subsequent reads may continue waiting beyond the configured deadline. The report targets a specified source version; it is not an incident report from a production environment. Issue and reproduction code
According to the author’s analysis, requestRaw() creates a timer driven by AbortController but always clears it in a finally block. The regular JSON path waits for the body to be decoded first, while the streaming path returns a readable stream early, allowing cleanup to run before data consumption finishes. As a result, the same timeout setting has a different effective scope for the two response modes. Code path explanation in the report
The author replaced fetch with an in-memory Response to simulate a body that remains open. With a 20 ms timeout and retries disabled, the JSON control case threw a TimeoutError, while SSE and binary reads were still unfinished at the end of a 120 ms observation period. This test isolates the timer management issue; it did not call a Dify server or model, so it cannot establish stall durations or incidence rates in real network conditions. Test setup and limitations
Engineering teams need to distinguish the point when a request receives a response, when body reading completes, and when a cancellation signal fires. The official Node.js documentation explains that AbortController is used to send a cancellation signal, while AbortSignal.timeout() triggers a signal after a specified time. Applications still need to ensure that the actual read path receives and handles cancellation. Node.js documentation
As of this review, the issue remains open, and the status of any production fix has not been confirmed. The key question is how maintainers define the streaming deadline: whether it covers the entire response or uses a separate idle timeout for periods without data. Based on this issue, regression tests should also cover normal completion, read failures, and explicit destruction, and confirm that errors reach the consumer. This would help avoid extending the timer while leaving gaps in cleanup or error propagation.