Back Home

GitHub Repo

Dify Community Proposes Trigger Isolation Fix After Unpublished Draft May Interrupt Production Workflow Events

A Dify community report on October 14 said editing an Integration Trigger draft could immediately stop a published workflow from receiving events, without leaving failed execution records. A proposed fix includes two regression tests but has not been merged; effects on other integration triggers remain unverified.

The original uploader was Ggia at Greek Wikipedia. · CC BY-SA 2.5 · Image source
zh-Hant

Doubts have emerged about the isolation between Dify drafts and production workflows. On October 14, a user reported that in a Cloud environment labeled 1.17.1, an unpublished draft could affect a published Integration Trigger workflow: clearing a subscription, deleting a trigger node, or reimporting exported settings into the same app could stop the production workflow from receiving events. The public report reproduces the behavior with GitHub Star events; it does not establish that all integrations behave the same way. Issue report

This behavior conflicts with users’ expectations about the publishing boundary. Dify’s official guide says changes take effect after the workflow is published again. If saving a draft can alter the production event entry point, engineers adjusting the next version of a workflow could also disrupt existing automation. Official publishing guide

The key observation in the report is that “no execution record” appears. The tester first confirmed that a Star event could start the workflow, then removed the draft subscription. Subsequent events produced no success or failure record. The production workflow resumed when the subscription was selected again in the draft, without publishing it. This points troubleshooting toward the event-to-workflow binding rather than downstream model nodes. Reproduction steps

A proposed fix, PR #44068, was submitted the same day. It binds trigger registration to a publish-specific signal so that draft synchronization preserves triggers used by the production workflow. The author said two targeted regression tests failed before the fix and passed afterward, and that Ruff, formatting, and diff checks were completed. At the time of review, the proposal was still open for review; it should not be treated as a fix in an official release. Proposed fix and validation

For operations teams, this case suggests that monitoring workflow failure rates alone may miss events that never create an execution. Based on the reported behavior, a more useful validation approach is to compare event receipt and execution counts before and after draft changes in a test environment, and to test the settings import path separately. Follow-up should track whether maintainers confirm the root cause, whether the fix is merged, and whether tests for other Integration Triggers are added before release. The two regression tests do not yet prove that the full cloud event pipeline has been restored.

Sources

  1. Integration Trigger: draft changes stop the published workflow from receiving events #44063
  2. fix(api): preserve published triggers on draft sync #44068
  3. 30-Minute Quick Start:Publish & Share