Dify 社群回報停止流程仍啟動排隊節點，取消指令可能未阻斷後續工具呼叫

Dify 的工作流程停止機制出現新的佇列處理回報。貢獻者於 10 月 20 日指出，在自行部署的主分支版本 ac17912 中，即使流程的中止狀態或 Redis 停止旗標已設定，工作程序仍可能取得先前排隊的節點並開始執行。這使取消操作的實際邊界，延伸到模型與工具呼叫的成本及副作用。問題回報

回報將問題定位在 StopAwareReadyQueue：目前加入任務的 put() 路徑會檢查停止條件，取出任務的 get() 卻直接交由內層佇列處理。因此，停止訊號可以阻擋新任務入列，卻擋不住已在佇列內等待的工作。重現方式是先放入一個 StartTask，再以已中止的流程狀態呼叫取件；回報者表示，系統仍回傳該任務。平行分支搭配單一工作程序，是可能出現此情境的例子。重現步驟

同日提出的修補改在取件時檢查停止狀態，將待執行任務標記完成並拋出 queue.Empty，避免工作程序啟動排隊節點；已經執行中的節點仍可能完成。作者表示，新增回歸案例在原始主分支會失敗，套用修補後，相關測試共 69 項通過。這提供了具體驗證線索，但提案仍開放等待審查，不能據此認定正式發行版已修復。修補提案與驗證說明

對 API 整合者，官方文件區分了控制當次生成的 task_id，以及追蹤持久化執行紀錄的 workflow_run_id；停止端點使用前者。依此問題的機制推論，工程團隊驗證取消行為時，應同時觀察節點開始時間、工具端請求與執行紀錄，確認停止後是否仍產生新操作。尤其是會寫入外部系統的流程，需要測試排隊分支的取消邊界。官方串流文件

目前證據來自社群提供的主分支重現與修補測試，尚未看到維護者對完整影響範圍的確認，也沒有雲端事故或實際損失證據。接下來應追蹤提案審查、合併狀態，以及哪些正式版本納入修正。