Human Input workflow still ends with "Stopped by user" after confirmation on latest main branch

[Jay-Jjq]

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

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Deploy the self-hosted Dify Community Edition from the latest main branch.
Create a Workflow application.
Create a simple workflow similar to:
Start
↓
Human Input
↓
Any downstream node
↓
End
Configure the Human Input node with a confirmation/action button.
Run the workflow.
Wait until the workflow reaches the Human Input node.
The workflow correctly enters the paused state and displays the Human Input form.
Click the confirmation/action button.
Observe the workflow execution status.

✔️ Expected Behavior

After confirming the Human Input form, the paused workflow should resume from the Human Input node.

For example:

Start
↓
Human Input (Paused)
↓
User confirms
↓
Resume workflow
↓
Execute downstream nodes
↓
End
↓
Succeeded

The workflow should finish with:

Succeeded

unless a downstream node actually fails.

❌ Actual Behavior

After clicking the Human Input confirmation button, the workflow resumes or attempts to resume, but the workflow is subsequently marked as:

Stopped by user.

I did not manually stop the workflow.

The downstream workflow execution is therefore interrupted or shown as stopped.

[dosubot]

Hi @Jay-Jjq! I'm Dosu and I'm helping the Dify team.

This is a regression introduced by PR #39186 in 1.16.0, and it has been tracked extensively in #39448 and #39750 [1] [2].

Root cause: When the workflow reaches the Human Input node and publishes QueueWorkflowPausedEvent, the listen() generator's finally block in base_app_queue_manager.py checks whether _execution_terminal was set. Since QueueWorkflowPausedEvent was missing from the terminal-event set in WorkflowAppQueueManager, _execution_terminal stayed unset, and the finally block called _abort_execution(...). This set a Redis stop flag keyed on task_id. Because the resumed execution reuses the same task_id, the GraphEngine picks up the stale stop flag and aborts the resumed run — resulting in "Stopped by user" even though you never manually stopped it [1].

Two fixes have already merged into main:

1. PR #39485 (merged 2025-07-30): Added QueueWorkflowPausedEvent to the terminal-event set in WorkflowAppQueueManager, so a legitimate pause no longer sets the stale abort flag [3].

2. PR #39813 (merged 2025-08-13): A more comprehensive fix introducing AppExecutionCoordinator, which fully decouples execution cancellation from the response-listener lifecycle. Paused vs. terminal states are modeled explicitly, so HITL resume cannot inherit cancellation from an earlier listener segment [4].

Why you're still seeing this on 1.16.1: Both PRs landed after 1.16.1 was tagged. The fix is currently only on main.

Immediate workaround while waiting for a patch release — apply the targeted change from PR #39485 directly in the container. In api/core/app/apps/workflow/app_queue_manager.py, add QueueWorkflowPausedEvent to the imports and to the isinstance terminal-event tuple [2]:

if isinstance(
    event,
    QueueStopEvent | QueueErrorEvent | QueueMessageEndEvent |
    QueueWorkflowSucceededEvent | QueueWorkflowFailedEvent |
    QueueWorkflowPartialSuccessEvent | QueueWorkflowPausedEvent,  # Add this
):
    self.stop_listen(execution_terminal=True)

Then restart the API container.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.