分析结论

执行 1200 秒的 workflow 被 "Stopped by user" 终止。最可能的原因不是使用者手动停止，而是应用级别的超时机制自动终止了工作流，但消息文案有误导性。

根本原因的观点是，APP_MAX_EXECUTION_TIME 默认 1200 秒超时

文件: init.py 第 - 行

APP_MAX_EXECUTION_TIME: PositiveInt = Field(
description="Maximum allowed execution time for application in seconds",default=1200,)

关键代码: base_app_queue_manager.py 第 - 行

def listen:
listen_timeout = dify_config.APP_MAX_EXECUTION_TIME # 默认 1200s
start_time = time.time
while True:
...
finally:
elapsed_time = time.time - start_time
if elapsed_time>= listen_timeout or self._is_stopped:
# ⚠️ 发布 QueueStopEvent。但 stopped_by 硬编码为 USER_MANUAL
self.publish(
QueueStopEvent,PublishFrom.TASK_PIPELINE
)

至于陷阱，超时也被标记为 "Stopped by user"

listen 方法中，无论是超时还是使用者手动停止都走到同一个分支，发布 stopped_by=USER_MANUAL 的 QueueStopEvent对应消息为 "Stopped by user.".

This means:

• Your workflow ran for 1200 秒.
• The default value of APP_MAX_EXECUTION_TIME is also 1200 秒.
• A timeout automatically terminated it.
• BUT because of code design,message shows as "Stopped by user".

从使用者痛点一来看，误导性错误信息导致无法判断真实原因。

- 在日志里看到 “Stopped by user”，却不知道是因为程序超时；- 调试时间被浪费在排查手动停止或权限问题上；- 对业务流程影响大，却缺少明确反馈。说起来，

说到使用者痛点二。默认超时时间过短，不符合实际业务场景。

- 大型数据处理或模型推理常常需要更长时间；说起来，- 超时导致任务中断，必须重跑耗费资源；老实说，- 缺乏灵活配置导致业务上线困难。

再看使用者痛点三，代码缺陷无法从事件区分超时与手动停止。

• No clear enum value distinguishing timeout vs manual stop.
• This leads to ambiguity when monitoring or alerting.
• Lack of audit trail makes compliance checks hard.

还有另一个独立超时：WORKFLOW_MAX_EXECUTION_TIME

WORKFLOW_MAX_EXECUTION_TIME: PositiveInt = Field(
description="Maximum execution time in seconds for a single workflow"。default=3600,)

This configuration is applied in workflow_entry.py at GraphEngine's ExecutionLimitsLayer; if triggered it follows a different failure path and does NOT display "Stopped by user". This can cause even more confusion if both limits are hit simultaneously.

Root Cause: APP_MAX_EXECUTION_TIME default 1200s timeout .

问题	详情
"Stopped by user"	This message appears even when timeout occurs;misleading for users.
User-facing pain points:	Mistakenly think it's a manual stop;cannot quickly identify real cause;wasted debugging effort;high resource cost due to re-runs.

从验证方法来看，

• # 检查数据库表记录是否符合预期运行时间：  SELECT finished_at - created_at FROM WorkflowRun WHERE id=;按理说，若差值 ≈ 1200 秒。则说明触发了 APP_MAX_EXECUTION_TIME 超时。

至于方法，

• # 如果你的 workflow 确实需要超过 1200 秒执行时间，可以通过环境变量增大超时配置：  

  $ cat .env
  APPMAXEXECUTIONTIME=7200 # 队列监听器超时改为 2 小时
  WORKFLOWMAXEXECUTIONTIME=7200 # GraphEngine 执行限制也改为 2 小时

$ systemctl restart dify.service # 或相应命令重新加载配置

# 注意事项： 

• Avoid setting too high values which may hide real issues.
• Create monitoring alerts on actual run times versus configured limits.

# 建议改进代码以区分超时与手动停止： 

• Add separate enum values e.g.。STOPBY.TIMEOUT vs STOPBY.USER_MANUAL.
• Migrate publish logic accordingly so messages accurately reflect cause.
--!---

-->

---