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

The workflow status isn’t updated correctly when the workflow is manually stopped. #21058

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

Originally created by @Kevin9703 on GitHub (Dec 15, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • 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, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.1

Cloud or Self Hosted

Cloud

Steps to reproduce

  1. Run the workflow.
  2. Before the workflow finishes, click the Stop button.

✔️ Expected Behavior

The workflow status should be updated to "Stopped" after clicking Stop.

❌ Actual Behavior

The workflow status always remains "Running".

Image Image
Originally created by @Kevin9703 on GitHub (Dec 15, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.11.1 ### Cloud or Self Hosted Cloud ### Steps to reproduce 1. Run the workflow. 2. Before the workflow finishes, click the Stop button. ### ✔️ Expected Behavior The workflow status should be updated to "Stopped" after clicking Stop. ### ❌ Actual Behavior The workflow status always remains "Running". <img width="818" height="698" alt="Image" src="https://github.com/user-attachments/assets/dc6de0fd-189e-45fc-9348-47a802a3b3b8" /> <img width="836" height="342" alt="Image" src="https://github.com/user-attachments/assets/da68290d-66f3-4279-ae54-e0d7cf0ab92d" />
yindo added the 🐞 bugcloud labels 2026-02-21 20:10:29 -05:00
yindo closed this issue 2026-02-21 20:10:29 -05:00
yindo commented 2026-02-21 20:10:29 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 15, 2025):

This bug is confirmed in Dify v1.11.1 (cloud): when you manually stop a workflow, its status often stays "Running" instead of updating to "Stopped". The root cause is that the stop API only sets a stop flag and sends a stop command, but the actual status change depends on the backend emitting a specific abort event—which sometimes doesn't happen, leaving the workflow stuck "Running".

This has been fixed in newer versions. The solution was to ensure the stop command is always sent and the abort event is properly handled, so the workflow status reliably updates to "Stopped" when you click Stop. You can see the relevant fix in PR #27803.

If you can't upgrade right now, workarounds include manually updating the workflow status in the database, using admin APIs to mark stuck workflows as stopped, or enabling debug logging for workflow persistence to diagnose silent failures. For a permanent fix, upgrading to the latest version is recommended.

There are also some known limitations: for example, you can't forcibly break out of an iterate node mid-execution, but future releases plan to address this with a Loop node that supports breaking out early.

Let me know if you need details on manual workarounds or want to see the relevant code paths.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 15, 2025): <!-- Answer --> This bug is confirmed in Dify v1.11.1 (cloud): when you manually stop a workflow, its status often stays "Running" instead of updating to "Stopped". The root cause is that the stop API only sets a stop flag and sends a stop command, but the actual status change depends on the backend emitting a specific abort event—which sometimes doesn't happen, leaving the workflow stuck ["Running"](https://github.com/langgenius/dify/blob/a8f3061b3c9350e1570979794e5cb521dd60a2da/api/controllers/console/app/workflow.py#L530-L592). This has been fixed in newer versions. The solution was to ensure the stop command is always sent and the abort event is properly handled, so the workflow status reliably updates to "Stopped" when you click Stop. You can see the relevant fix in [PR #27803](https://github.com/langgenius/dify/pull/27803). If you can't upgrade right now, workarounds include manually updating the workflow status in the database, using admin APIs to mark stuck workflows as stopped, or enabling debug logging for workflow persistence to diagnose silent failures. For a permanent fix, upgrading to the latest version is recommended. There are also some known limitations: for example, you can't forcibly break out of an iterate node mid-execution, but future releases plan to address this with a Loop node that supports breaking out early. Let me know if you need details on manual workarounds or want to see the relevant code paths. <!-- 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/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e3f6e048-12a6-4b0d-836f-04ef32c7bda7?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20bug%20is%20confirmed%20in%20Dify%20v1.11.1%20%28cloud%29%3A%20when%20you%20manually%20stop%20a%20workflow%2C%20its%20status%20often%20stays%20%22Running%22%20instead%20of%20updating%20to%20%22Stopped%22.%20The%20root%20cause%20is%20that%20the%20stop%20API%20only%20sets%20a%20stop%20flag%20and%20sends%20a%20stop%20command%2C%20but%20the%20actual%20status%20change%20depends%20on%20the%20backend%20emitting%20a%20specific%20abort%20event%E2%80%94which%20sometimes%20doesn%27t%20happen%2C%20leaving%20the%20workflow%20stuck%20%5B%22Running%22%5D%28https%3A//github.com/langgenius/dify/blob/a8f3061b3c9350e1570979794e5cb521dd60a2da/api/controllers/console/app/workflow.py%23L530-L592%29.%0A%0AThis%20has%20been%20fixed%20in%20newer%20versions.%20The%20solution%20was%20to%20ensure%20the%20stop%20command%20is%20always%20sent%20and%20the%20abort%20event%20is%20properly%20handled%2C%20so%20the%20workflow%20status%20reliably%20updates%20to%20%22Stopped%22%20when%20you%20click%20Stop.%20You%20can%20see%20the%20relevant%20fix%20in%20%5BPR%20%2327803%5D%28https%3A//github.com/langgenius/dify/pull/27803%29.%0A%0AIf%20you%20can%27t%20upgrade%20right%20now%2C%20workarounds%20include%20manually%20updating%20the%20workflow%20status%20in%20the%20database%2C%20using%20admin%20APIs%20to%20mark%20stuck%20workflows%20as%20stopped%2C%20or%20enabling%20debug%20logging%20for%20workflow%20persistence%20to%20diagnose%20silent%20failures.%20For%20a%20permanent%20fix%2C%20upgrading%20to%20the%20latest%20version%20is%20recommended.%0A%0AThere%20are%20also%20some%20known%20limitations%3A%20for%20example%2C%20you%20can%27t%20forcibly%20break%20out%20of%20an%20iterate%20node%20mid-execution%2C%20but%20future%20releases%20plan%20to%20address%20this%20with%20a%20Loop%20node%20that%20supports%20breaking%20out%20early.%0A%0ALet%20me%20know%20if%20you%20need%20details%20on%20manual%20workarounds%20or%20want%20to%20see%20the%20relevant%20code%20paths.)&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/29688)
yindo commented 2026-02-21 20:10:29 -05:00
Author
Owner
Copy Link
Copy Source

@Kevin9703 commented on GitHub (Dec 15, 2025):

This might be related to this snippet:

https://github.com/langgenius/dify/blob/a8f3061b3c9350e1570979794e5cb521dd60a2da/api/core/workflow/graph_engine/orchestration/dispatcher.py#L96-L102

When the event queue is empty, the dispatcher just sleep and never poll the command channel.
A user “stop” action is delivered as an external command (e.g., abort) rather than a queue event, so it wouldn’t be processed until some event arrived (often only after a long-running node finished).

#27803 is only effective for the 1.9.x version; after upgrading to 1.10, it no longer works.

@Kevin9703 commented on GitHub (Dec 15, 2025): This might be related to this snippet: https://github.com/langgenius/dify/blob/a8f3061b3c9350e1570979794e5cb521dd60a2da/api/core/workflow/graph_engine/orchestration/dispatcher.py#L96-L102 When the event queue is empty, the dispatcher just sleep and never poll the command channel. A user “stop” action is delivered as an external command (e.g., abort) rather than a queue event, so it wouldn’t be processed until some event arrived (often only after a long-running node finished). #27803 is only effective for the 1.9.x version; after upgrading to 1.10, it no longer works.
yindo commented 2026-02-21 20:10:29 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 15, 2025):

You're exactly right—the issue is caused by the dispatcher not polling the command channel when the event queue is empty in v1.11.1. When no new events arrive (like during a long-running node), the dispatcher just sleeps and doesn't check for external commands such as user "stop" actions. This means stop requests aren't processed until another event wakes the dispatcher, which can leave workflows stuck in "Running" for a long time even after you click Stop. You can see this logic in the dispatcher loop: it only processes commands when an event is received, not during idle periods, which matches your observation (source).

This was fixed in later versions. The dispatcher was updated to poll for commands even when idle, so abort/stop requests are handled promptly and workflow status updates correctly (PR #26998). If you're on v1.11.1, the only workarounds are to manually update stuck workflow statuses or upgrade to a newer version where this is resolved.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 15, 2025): <!-- Answer --> You're exactly right—the issue is caused by the dispatcher not polling the command channel when the event queue is empty in v1.11.1. When no new events arrive (like during a long-running node), the dispatcher just sleeps and doesn't check for external commands such as user "stop" actions. This means stop requests aren't processed until another event wakes the dispatcher, which can leave workflows stuck in "Running" for a long time even after you click Stop. You can see this logic in the dispatcher loop: it only processes commands when an event is received, not during idle periods, which matches your observation [(source)](https://github.com/langgenius/dify/blob/09982a1c95e1ce65981cfeef2c6da852b74678a2/api/core/workflow/graph_engine/orchestration/dispatcher.py#L83-L126). This was fixed in later versions. The dispatcher was updated to poll for commands even when idle, so abort/stop requests are handled promptly and workflow status updates correctly [(PR #26998)](https://github.com/langgenius/dify/pull/26998). If you're on v1.11.1, the only workarounds are to manually update stuck workflow statuses or upgrade to a newer version where this is resolved. <!-- 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/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/22a84692-692e-41fe-ad7f-533d431fb32a?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=You%27re%20exactly%20right%E2%80%94the%20issue%20is%20caused%20by%20the%20dispatcher%20not%20polling%20the%20command%20channel%20when%20the%20event%20queue%20is%20empty%20in%20v1.11.1.%20When%20no%20new%20events%20arrive%20%28like%20during%20a%20long-running%20node%29%2C%20the%20dispatcher%20just%20sleeps%20and%20doesn%27t%20check%20for%20external%20commands%20such%20as%20user%20%22stop%22%20actions.%20This%20means%20stop%20requests%20aren%27t%20processed%20until%20another%20event%20wakes%20the%20dispatcher%2C%20which%20can%20leave%20workflows%20stuck%20in%20%22Running%22%20for%20a%20long%20time%20even%20after%20you%20click%20Stop.%20You%20can%20see%20this%20logic%20in%20the%20dispatcher%20loop%3A%20it%20only%20processes%20commands%20when%20an%20event%20is%20received%2C%20not%20during%20idle%20periods%2C%20which%20matches%20your%20observation%20%5B%28source%29%5D%28https%3A//github.com/langgenius/dify/blob/09982a1c95e1ce65981cfeef2c6da852b74678a2/api/core/workflow/graph_engine/orchestration/dispatcher.py%23L83-L126%29.%0A%0AThis%20was%20fixed%20in%20later%20versions.%20The%20dispatcher%20was%20updated%20to%20poll%20for%20commands%20even%20when%20idle%2C%20so%20abort/stop%20requests%20are%20handled%20promptly%20and%20workflow%20status%20updates%20correctly%20%5B%28PR%20%2326998%29%5D%28https%3A//github.com/langgenius/dify/pull/26998%29.%20If%20you%27re%20on%20v1.11.1%2C%20the%20only%20workarounds%20are%20to%20manually%20update%20stuck%20workflow%20statuses%20or%20upgrade%20to%20a%20newer%20version%20where%20this%20is%20resolved.)&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/29688)
yindo commented 2026-02-21 20:10:30 -05:00
Author
Owner
Copy Link
Copy Source

@eviltik commented on GitHub (Dec 30, 2025):

Same issue as #18481 - this is a blocker for production environments.

When using Dify with Ollama (especially with reasoning models like Qwen3 that can hallucinate infinitely in <think> blocks), the inability to actually stop a running workflow leads to:

  1. Resource exhaustion: Ollama continues generating tokens indefinitely, consuming GPU/CPU resources
  2. Poor user experience: Users click "Stop" expecting the generation to halt, but it keeps running in the background
  3. No workaround possible: Since Dify maintains its own HTTP connection to Ollama, external systems cannot interrupt it - only Dify can close that connection

The root cause: When the stop API is called, Dify returns {"result": "success"} but does NOT close the HTTP connection to the LLM provider (Ollama). According to Ollama's behavior, closing the HTTP connection is the signal to stop generation.

Related issues: #6493, #18481, #12798

@eviltik commented on GitHub (Dec 30, 2025): Same issue as #18481 - this is a **blocker for production environments**. When using Dify with Ollama (especially with reasoning models like Qwen3 that can hallucinate infinitely in `<think>` blocks), the inability to actually stop a running workflow leads to: 1. **Resource exhaustion**: Ollama continues generating tokens indefinitely, consuming GPU/CPU resources 2. **Poor user experience**: Users click "Stop" expecting the generation to halt, but it keeps running in the background 3. **No workaround possible**: Since Dify maintains its own HTTP connection to Ollama, external systems cannot interrupt it - only Dify can close that connection **The root cause**: When the stop API is called, Dify returns `{"result": "success"}` but does NOT close the HTTP connection to the LLM provider (Ollama). According to Ollama's behavior, closing the HTTP connection is the signal to stop generation. Related issues: #6493, #18481, #12798
yindo commented 2026-02-21 20:10:30 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 30, 2026):

Hi, @Kevin9703. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that in Dify v1.11.1 (Cloud), manually stopping a running workflow does not update its status to "Stopped," leaving it as "Running."
  • The root cause was the dispatcher not polling the command channel when the event queue is empty.
  • This was fixed in later versions by updating the dispatcher to handle stop commands promptly (PR #26998).
  • You noted that the fix in PR #27803 only applies to v1.9.x, not v1.11.1.
  • Another user highlighted this as a production blocker, especially with Ollama models that run indefinitely, causing resource exhaustion and poor UX.

What's Next:

  • Please check if this issue is still relevant with the latest version of Dify; if so, you can keep the discussion open by commenting here.
  • Otherwise, I will automatically close this issue in 15 days.

Thanks for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 30, 2026): Hi, @Kevin9703. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that in Dify v1.11.1 (Cloud), manually stopping a running workflow does not update its status to "Stopped," leaving it as "Running." - The root cause was the dispatcher not polling the command channel when the event queue is empty. - This was fixed in later versions by updating the dispatcher to handle stop commands promptly (PR #26998). - You noted that the fix in PR #27803 only applies to v1.9.x, not v1.11.1. - Another user highlighted this as a production blocker, especially with Ollama models that run indefinitely, causing resource exhaustion and poor UX. **What's Next:** - Please check if this issue is still relevant with the latest version of Dify; if so, you can keep the discussion open by commenting here. - Otherwise, I will automatically close this issue in 15 days. Thanks for your understanding and contribution!
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 cloud 🐞 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#21058
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?