GitHub Repo
Dify Community Reports Duplicate Scheduled Executions; Concurrent Publishing May Create Duplicate Triggers
A Dify community report on October 28 says that concurrently publishing a workflow may create duplicate triggers, causing each schedule to run multiple times. The report proposes a query-layer fix, but as of review, maintainers had not confirmed the issue or provided a verifiable merge result.
On October 28, the Dify community reported a schedule consistency issue: two requests publishing a workflow with a Schedule trigger at the same time may create multiple active trigger records for the same node. The report covers the self-hosted main branch and includes a commit version and reproduction steps. For now, it should be treated as an unconfirmed bug report; its scope cannot yet be assumed to include all production releases. Issue report
According to the reporter’s analysis, the publishing process follows a “query, then insert” pattern: two transactions may both fail to find an existing record, then each insert one. app_triggers has no uniqueness constraint on (app_id, node_id). The schedule poller then joins trigger data on those two fields, potentially expanding one schedule plan into multiple dispatches. If this behavior is confirmed, model calls and external tool operations could both occur more than once. Reproduction conditions and root cause analysis
The report proposes replacing the join query with an EXISTS condition so duplicate triggers do not increase the number of results, while retaining FOR UPDATE SKIP LOCKED. This choice reflects a database limitation: PostgreSQL does not allow DISTINCT to be used with row-locking clauses. SKIP LOCKED skips rows locked by other transactions, making it suitable for queues handled by multiple consumers. Simply adding a deduplication keyword would not preserve the existing locking behavior. PostgreSQL SELECT documentation
From an engineering perspective, deduplicating the query can limit dispatch results, but the source of the duplicate data still needs to be addressed. The report also recommends adding a uniqueness constraint, cleaning up existing duplicate records, and making publish writes idempotent. Deployment teams can first compare trigger counts and execution records for the same application and node. They should then track whether maintainers can reproduce the issue, whether the fix includes a data migration, and when it will be included in a production release. As of this review, the proposed patch content could not be retrieved successfully, so the issue cannot be described as fixed. Patch proposal and follow-up recommendations