Dify 社群回報排程重複執行，並行發布可能建立重複觸發器

Dify 社群於 10 月 28 日提出排程一致性問題：兩個請求同時發布含 Schedule 觸發器的工作流程，可能讓同一節點產生多筆啟用中的觸發器紀錄。回報針對自行部署的 main 分支，列出提交版本與重現步驟；目前應視為待確認的缺陷回報，影響範圍尚不能擴大到所有正式版本。問題回報

依回報者分析，發布流程採取「先查詢、再新增」：兩筆交易可能同時查不到既有紀錄，接著各自寫入。app_triggers 缺少對 (app_id, node_id) 的唯一性約束；排程輪詢器再以這兩個欄位連接觸發器資料，便可能把同一排程計畫展開成多筆派送。若此行為成立，模型呼叫與外部工具操作都可能重複發生。重現條件與原因分析

回報提出以 EXISTS 存在性條件取代連接查詢，讓重複觸發器不再增加結果筆數，同時保留 FOR UPDATE SKIP LOCKED。這項選擇有資料庫限制背景：PostgreSQL 不允許 DISTINCT 與列鎖定子句同用；SKIP LOCKED 則會略過已被其他交易鎖定的資料列，適合多個消費者處理佇列的情境。單純加入去重關鍵字，無法直接保留原有鎖定方式。PostgreSQL SELECT 文件

工程上，查詢去重只能限制派送結果，仍須處理重複資料的來源。回報也建議後續加入唯一性約束、清理既有重複紀錄，並讓發布寫入具備冪等性。部署團隊可先比對同一應用與節點的觸發器筆數及執行紀錄；後續應追蹤維護者能否重現、修補是否包含資料遷移，以及正式版本何時納入。截至本次查核，相關修補請求內容未能成功取得，不能宣稱問題已修復。修補提案與後續建議