langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 12:36:14 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

When variables in the workflow are deleted or modified, it is impossible to visually identify subsequent node errors #13158

New Issue
Closed
opened 2026-02-21 19:10:49 -05:00 by yindo · 5 comments
yindo commented 2026-02-21 19:10:49 -05:00
Owner
Copy Link
Copy Source

Originally created by @tinet-dongfb on GitHub (Apr 21, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.2.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The main issue is that it is complex to troubleshoot problems when there are a large number of nodes, and similar problems also exist in other types of nodes. The following is the simplest reproduction situation：

TakeKnowledge retrieval nodes as an example：

  1. Add a start variable, and the variable name is "start"
  2. Add the Knowledge retrieval node and select the previously configured start variable "start" in the context configuration of the Knowledge retrieval node
  3. Delete the connection between the LLM and the start node, and modify the "start" variable in the start variable
  4. Connect the start node and the Knowledge retrieval node, add the end node, and click Publish
  5. At this point, an error was found during operation, but there was no prompt in the page configuration

Screenshot display：

Image Image

✔️ Expected Behavior

If an unobtainable variable is used in a node, the variable can be automatically deleted or prompted before publication；

❌ Actual Behavior

It wasn't deleted and there was no prompt. The problem to be investigated is complicated

Originally created by @tinet-dongfb on GitHub (Apr 21, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.2.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce **The main issue is that it is complex to troubleshoot problems when there are a large number of nodes, and similar problems also exist in other types of nodes. The following is the simplest reproduction situation：** **TakeKnowledge retrieval nodes as an example**： 1. Add a start variable, and the variable name is "start" 2. Add the Knowledge retrieval node and select the previously configured start variable "start" in the context configuration of the Knowledge retrieval node 3. Delete the connection between the LLM and the start node, and modify the "start" variable in the start variable 4. Connect the start node and the Knowledge retrieval node, add the end node, and click Publish 5. At this point, an error was found during operation, but there was no prompt in the page configuration **Screenshot display**： <img width="1423" alt="Image" src="https://github.com/user-attachments/assets/1f78c6dd-7547-422b-ad71-6b1312c9187e" /> <img width="1441" alt="Image" src="https://github.com/user-attachments/assets/e7465de2-95d1-4285-9f17-1da4e2b6bb88" /> ### ✔️ Expected Behavior If an unobtainable variable is used in a node, the variable can be automatically deleted or prompted before publication； ### ❌ Actual Behavior It wasn't deleted and there was no prompt. The problem to be investigated is complicated
yindo added the 🌊 feat:workflow label 2026-02-21 19:10:49 -05:00
yindo closed this issue 2026-02-21 19:10:49 -05:00
yindo commented 2026-02-21 19:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Apr 21, 2025):

Hello @tinet-dongfb! I'm Dosu, your friendly bot here to help you tackle bugs, answer questions, and guide you on contributing. While you wait for a human maintainer, feel free to let me know how I can assist you!

I found a similar issue that was previously reported and closed: Components related to variable references should maintain consistent behavior in the event of variable errors or similar issues. This issue was resolved by a pull request that introduced an error prompt when a variable does not exist [1].

In your case, it seems that when variables in the workflow are deleted or modified, subsequent node errors are not visually identifiable, which complicates troubleshooting. The expected behavior would be for the system to either automatically delete unobtainable variables or provide a prompt before publication. However, this is not currently happening, and there is no prompt indicating the issue during the page configuration.

You might want to check if the solution from the previous issue has been integrated into your version (1.2.0) or if there are any updates or patches available that address this problem.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Apr 21, 2025): <!-- Greeting --> Hello @tinet-dongfb! I'm [Dosu](https://dosu.dev), your friendly bot here to help you tackle bugs, answer questions, and guide you on contributing. While you wait for a human maintainer, feel free to let me know how I can assist you! <!-- Answer --> I found a similar issue that was previously reported and closed: [Components related to variable references should maintain consistent behavior in the event of variable errors or similar issues](https://github.com/langgenius/dify/issues/8412). This issue was resolved by a pull request that introduced an error prompt when a variable does not exist <sup>[[1]](https://github.com/langgenius/dify/issues/8412)</sup>. In your case, it seems that when variables in the workflow are deleted or modified, subsequent node errors are not visually identifiable, which complicates troubleshooting. The expected behavior would be for the system to either automatically delete unobtainable variables or provide a prompt before publication. However, this is not currently happening, and there is no prompt indicating the issue during the page configuration. You might want to check if the solution from the previous issue has been integrated into your version (1.2.0) or if there are any updates or patches available that address this problem. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e42e2bd9-547e-423a-8cbe-c70d81c260a7?feedback_type=other)</sup>
yindo commented 2026-02-21 19:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@tinet-dongfb commented on GitHub (Apr 21, 2025):

@dosu

This issue is not consistent. First of all, its prompt needs to be opened before it can be prompted. And after many iterations now, this prompt function is still not perfect.
I hope that incorrect variables should not lead to the successful release of the workflow. Perhaps they can better enable us to configure the workflow

@tinet-dongfb commented on GitHub (Apr 21, 2025): @dosu This issue is not consistent. First of all, its prompt needs to be opened before it can be prompted. And after many iterations now, this prompt function is still not perfect. I hope that incorrect variables should not lead to the successful release of the workflow. Perhaps they can better enable us to configure the workflow
yindo commented 2026-02-21 19:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Apr 21, 2025):

To prevent incorrect variables from leading to the successful release of a workflow, you can use the checkKeys function from the web/utils/var.ts file. This function validates variable keys against criteria such as length, format, and whether they start with a number. If a key fails validation, it returns an error message indicating the issue, allowing you to handle errors and prevent workflow release [1].

Additionally, you can improve the prompt function for better workflow configuration by using the getVars function. This function extracts and validates variable names from a string, ensuring they meet specific criteria and do not exceed the maximum allowed length [1].

For more robust workflow configuration, consider using the WorkflowToolConfigurationUtils class from the api/core/tools/utils/workflow_configuration_sync.py file. The check_parameter_configurations method validates each configuration, while the check_is_synced method ensures that variables and tool configurations match, raising a ValueError if they do not [2].

By leveraging these functions and utilities, you can ensure that only valid variables are used in the workflow configuration, preventing errors during release.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Apr 21, 2025): <!-- Answer --> To prevent incorrect variables from leading to the successful release of a workflow, you can use the `checkKeys` function from the `web/utils/var.ts` file. This function validates variable keys against criteria such as length, format, and whether they start with a number. If a key fails validation, it returns an error message indicating the issue, allowing you to handle errors and prevent workflow release <sup>[[1]](https://github.com/langgenius/dify/blob/main/web/utils/var.ts)</sup>. Additionally, you can improve the prompt function for better workflow configuration by using the `getVars` function. This function extracts and validates variable names from a string, ensuring they meet specific criteria and do not exceed the maximum allowed length <sup>[[1]](https://github.com/langgenius/dify/blob/main/web/utils/var.ts)</sup>. For more robust workflow configuration, consider using the `WorkflowToolConfigurationUtils` class from the `api/core/tools/utils/workflow_configuration_sync.py` file. The `check_parameter_configurations` method validates each configuration, while the `check_is_synced` method ensures that variables and tool configurations match, raising a `ValueError` if they do not <sup>[[2]](https://github.com/langgenius/dify/blob/main/api/core/tools/utils/workflow_configuration_sync.py)</sup>. By leveraging these functions and utilities, you can ensure that only valid variables are used in the workflow configuration, preventing errors during release. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5eb26553-e125-441f-a079-80e63185bb5c?feedback_type=other)</sup>
yindo commented 2026-02-21 19:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@tinet-dongfb commented on GitHub (Apr 21, 2025):

@dosu

Perhaps my expression was wrong. I hope that when there are incorrect variables in the node, the release of the workflow can be prevented.

Do you have any short-term plans for the improvement of this relatively strict configuration verification?
May I submit a pr to you?

@tinet-dongfb commented on GitHub (Apr 21, 2025): @dosu Perhaps my expression was wrong. I hope that when there are incorrect variables in the node, the release of the workflow can be prevented. Do you have any short-term plans for the improvement of this relatively strict configuration verification? May I submit a pr to you?
yindo commented 2026-02-21 19:10:50 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Apr 21, 2025):

To prevent the release of workflows with incorrect variables, Dify uses mechanisms like the checkValid function associated with each node type. This function validates node configurations before they are released in a workflow. For example, the VariableAssigner node's checkValid function checks for required fields and validates variables, returning an error message if any required fields are missing or invalid [1][2].

Regarding short-term plans for improving configuration verification, I couldn't find specific information on a roadmap or proposed changes in the repository. However, you can contribute by submitting a pull request to enhance the configuration verification process. This could involve improving existing validation functions or adding new checks to ensure stricter verification of node configurations before workflow release.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Apr 21, 2025): <!-- Answer --> To prevent the release of workflows with incorrect variables, Dify uses mechanisms like the `checkValid` function associated with each node type. This function validates node configurations before they are released in a workflow. For example, the `VariableAssigner` node's `checkValid` function checks for required fields and validates variables, returning an error message if any required fields are missing or invalid <sup>[[1]](https://github.com/langgenius/dify/blob/main/web/app/components/workflow/constants.ts)</sup><sup>[[2]](https://github.com/langgenius/dify/blob/main/web/app/components/workflow/nodes/variable-assigner/default.ts)</sup>. Regarding short-term plans for improving configuration verification, I couldn't find specific information on a roadmap or proposed changes in the repository. However, you can contribute by submitting a pull request to enhance the configuration verification process. This could involve improving existing validation functions or adding new checks to ensure stricter verification of node configurations before workflow release. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/ade80daf-915b-46df-baf3-d10f3e44f720?feedback_type=other)</sup>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🌊 feat:workflow
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#13158
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?