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

Conditional branching error: when there are two consecutive if-else nodes, the connecting color is lost when the second if node goes else #15230

New Issue
Closed
opened 2026-02-21 19:20:47 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 19:20:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @chenyi-666 on GitHub (Jul 9, 2025).

Originally assigned to: @Nov1c444 on GitHub.

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.5.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Step 1: Add if-else node in workflow and add a field name qq.
Step 2: Set a condition in the if-else node: if qq contains 3, it will go to if, otherwise it will go to else.
Step 3: After the if branch of the if-else node in step 2, connect another if-else node with the condition that if will be executed when qq contains 6, else will be executed otherwise.
Step 4: Add an end node after both the if branch and the else branch of the second if-else node in Step 3, outputting qq.
Step 5: Run the process and send 3 to the input box to see the results.

Image

✔️ Expected Behavior

1.Execution Flow Visualization:
The connecting lines between executed nodes correctly display their active color (indicating process flow).

2.Non-Executed Nodes:
Nodes that were not executed do not show the green checkmark execution indicator.

❌ Actual Behavior

1.First Issue:
When the second if-else node executes the else branch, the runtime color (indicating execution flow) should be visible. Currently, the green line representing the flow through this branch is not being displayed.

2.Second Issue:
The end node following the else branch of the first if-else node shows a green checkmark (indicating execution), which should theoretically be impossible since this branch should not be executed.

Originally created by @chenyi-666 on GitHub (Jul 9, 2025). Originally assigned to: @Nov1c444 on GitHub. ### 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.5.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Step 1: Add if-else node in workflow and add a field name qq. Step 2: Set a condition in the if-else node: if qq contains 3, it will go to if, otherwise it will go to else. Step 3: After the if branch of the if-else node in step 2, connect another if-else node with the condition that if will be executed when qq contains 6, else will be executed otherwise. Step 4: Add an end node after both the if branch and the else branch of the second if-else node in Step 3, outputting qq. Step 5: Run the process and send 3 to the input box to see the results. <img width="1672" height="429" alt="Image" src="https://github.com/user-attachments/assets/db6f4b33-c1cf-412d-a550-86389c61fce6" /> ### ✔️ Expected Behavior 1.Execution Flow Visualization: The connecting lines between executed nodes correctly display their active color (indicating process flow). 2.Non-Executed Nodes: Nodes that were not executed do not show the green checkmark execution indicator. ### ❌ Actual Behavior 1.First Issue: When the second if-else node executes the else branch, the runtime color (indicating execution flow) should be visible. Currently, the green line representing the flow through this branch is not being displayed. 2.Second Issue: The end node following the else branch of the first if-else node shows a green checkmark (indicating execution), which should theoretically be impossible since this branch should not be executed.
yindo added the 🐞 bugstale🌊 feat:workflow labels 2026-02-21 19:20:47 -05:00
yindo closed this issue 2026-02-21 19:20:47 -05:00
yindo commented 2026-02-21 19:20:47 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jul 9, 2025):

Hi @chenyi-666! I'm Dosu and I’m helping the dify team.

This looks like a visualization bug in how Dify tracks and displays execution flow for consecutive if-else nodes. The backend (GraphEngine and IfElseNode) correctly determines which branch is executed and emits events with branch info, but the frontend logic (React hooks and edge rendering) uses properties like _runningBranchId and edge statuses to color the lines and mark nodes as executed. If the branch-tracing logic doesn't propagate correctly—especially when chaining if-else nodes—the UI can lose the active color on the executed path or incorrectly show checkmarks on non-executed nodes. This matches your description.

Recent code changes have refactored node and edge state management, but there’s no direct evidence this specific bug is fixed in newer versions. The most likely failure point is in how the frontend updates edge and node statuses for conditional branches, especially in files like use-workflow-node-started.ts, use-workflow-node-finished.ts, and custom-edge.tsx (edge coloring logic) [custom-edge.tsx].

If you want to debug or patch this in 1.5.1, check that the event payloads for node execution include the correct branch IDs and that the frontend is using them to update only the actually executed path. You might want to log or inspect the _runningBranchId and edge status propagation in the workflow run data and React state.

No official workaround or config option is documented for this, but focusing on the branch ID propagation in the frontend is your best bet for a fix. If you upgrade to a newer version, keep an eye on related PRs like #21822 and #21882, as they touch relevant code but do not explicitly mention fixing this bug.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 9, 2025): <!-- Greeting --> Hi @chenyi-666! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> This looks like a visualization bug in how Dify tracks and displays execution flow for consecutive if-else nodes. The backend (GraphEngine and IfElseNode) correctly determines which branch is executed and emits events with branch info, but the frontend logic (React hooks and edge rendering) uses properties like `_runningBranchId` and edge statuses to color the lines and mark nodes as executed. If the branch-tracing logic doesn't propagate correctly—especially when chaining if-else nodes—the UI can lose the active color on the executed path or incorrectly show checkmarks on non-executed nodes. This matches your description. Recent code changes have refactored node and edge state management, but there’s no direct evidence this specific bug is fixed in newer versions. The most likely failure point is in how the frontend updates edge and node statuses for conditional branches, especially in files like `use-workflow-node-started.ts`, `use-workflow-node-finished.ts`, and `custom-edge.tsx` (edge coloring logic) [[custom-edge.tsx](https://github.com/langgenius/dify/blob/6f8c7a66c801ecd1239258a95dde035afba47f91/web/app/components/workflow/custom-edge.tsx)]. If you want to debug or patch this in 1.5.1, check that the event payloads for node execution include the correct branch IDs and that the frontend is using them to update only the actually executed path. You might want to log or inspect the `_runningBranchId` and edge status propagation in the workflow run data and React state. No official workaround or config option is documented for this, but focusing on the branch ID propagation in the frontend is your best bet for a fix. If you upgrade to a newer version, keep an eye on related PRs like #21822 and #21882, as they touch relevant code but do not explicitly mention fixing this bug. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5a8a815f-14a7-4925-81b9-3c0e2f0ae928?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/22124)
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 stale 🌊 feat:workflow 🐞 bug
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#15230
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?