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

问题场景

用户在使用 Dify 自托管社区版（Docker 部署）创建 Workflow 应用时，构建了一个包含 Start → Human Input（人工输入）→ 下游节点 → End 的简单工作流。当工作流执行到 Human Input 节点时，正确进入暂停状态并显示表单；用户点击确认/操作按钮后，工作流尝试恢复执行，但最终被系统标记为“Stopped by user”，导致下游节点无法正常执行。

报错原文

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

原因分析

这是一个由 PR #39186 在 1.16.0 版本中引入的回归问题。根本原因如下：当工作流到达 Human Input 节点并发布 QueueWorkflowPausedEvent 时，base_app_queue_manager.py 中 listen() 生成器的 finally 块会检查 _execution_terminal 是否被设置。由于 WorkflowAppQueueManager 的终止事件集合中缺少 QueueWorkflowPausedEvent，_execution_terminal 保持未设置状态，finally 块随后调用 _abort_execution(...)，在 Redis 中设置了基于 task_id 的停止标志。由于恢复执行时复用了相同的 task_id，GraphEngine 会读取到该过期的停止标志并中止恢复后的运行，最终导致“Stopped by user”。

环境排查

• 确认 Dify 版本是否为 1.16.1（或 1.16.0）——该回归从 1.16.0 开始引入。
• 检查部署方式是否为自托管 Docker 部署。
• 检查 api/core/app/apps/workflow/app_queue_manager.py 文件中终止事件判断的 isinstance 元组是否包含 QueueWorkflowPausedEvent。
• 验证 Redis 中是否存在与 task_id 相关的过期停止标志。

解决步骤

1. 紧急规避（可优先尝试）：进入 API 容器，编辑 api/core/app/apps/workflow/app_queue_manager.py。
2. 在文件顶部的导入部分添加 QueueWorkflowPausedEvent（如果尚未导入）。
3. 找到终止事件判断的 isinstance 元组，在其中增加 QueueWorkflowPausedEvent，使其变为：
   QueueStopEvent | QueueErrorEvent | QueueMessageEndEvent | QueueWorkflowSucceededEvent | QueueWorkflowFailedEvent | QueueWorkflowPartialSuccessEvent | QueueWorkflowPausedEvent
4. 保存修改并重启 API 容器。
5. 长期方案：等待或主动升级到包含 PR #39485（2025-07-30 合并）或更全面的 PR #39813（2025-08-13 合并）的 Dify 版本。PR #39813 引入的 AppExecutionCoordinator 从架构上解决了暂停与终止状态混淆的问题，建议优先采用。

验证方法

应用补丁或升级版本后，重新创建一个包含 Human Input 节点的 Workflow 应用，运行并等待暂停，点击确认按钮后观察工作流状态。如果修复生效，工作流应正常恢复并最终显示“Succeeded”（除非下游节点确实执行失败），不再出现“Stopped by user”的错误状态。

参考来源

langgenius/dify #40878

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。