GitHub Repo
Dify Community Reports Queued Nodes Starting After Workflow Stop, Potentially Allowing Later Tool Calls
A Dify community report on October 20 says queued nodes may still start after a workflow receives a stop signal, potentially adding model costs or triggering external actions. A proposed fix includes regression tests but has not been merged; the impact on official releases and the cloud service remains unconfirmed.
Dify’s workflow stop mechanism has drawn a new report about queue handling. On October 20, a contributor reported that in self-hosted main-branch version ac17912, a worker may retrieve and start a previously queued node even after the workflow’s aborted status or Redis stop flag has been set. This extends the practical limits of cancellation to the costs and side effects of model and tool calls. Issue report
The report locates the problem in StopAwareReadyQueue: the current put() path for adding tasks checks the stop condition, while get() retrieves tasks directly from the inner queue. As a result, a stop signal can block new tasks from being queued but may not prevent work already waiting in the queue from running. To reproduce the issue, first enqueue a StartTask, then call the retrieval method with an already-aborted workflow status; the reporter says the system still returns the task. A parallel branch combined with a single worker is one scenario in which this could occur. Reproduction steps
A fix proposed the same day checks the stop status during retrieval, marks pending tasks as complete, and raises queue.Empty to keep the worker from starting queued nodes. Nodes that are already running may still finish. The author says the new regression case fails on the original main branch and that 69 related tests pass with the fix applied. This provides a concrete verification signal, but the proposal remains open for review, so it does not establish that an official release has been fixed. Proposed fix and verification notes
For API integrators, the official documentation distinguishes task_id, which controls the current generation, from workflow_run_id, which tracks a persisted execution record; the stop endpoint uses the former. Based on the mechanism described in this issue, engineering teams validating cancellation should monitor node start times, requests received by tools, and execution records to check whether new operations occur after a stop. Workflows that write to external systems especially warrant testing the cancellation boundary for queued branches. Official streaming documentation
The current evidence comes from a community-provided main-branch reproduction and tests for the proposed fix. There has been no maintainer confirmation of the full scope, and no evidence of a cloud incident or actual losses. The next steps are to track the proposal’s review and merge status, and determine which official versions include the fix.