分析结论
执行 1200 秒的 workflow 被 "Stopped by user" 终止,最可能的原因不是用户手动停止,而是应用级别的超时机制自动终止了工作流,但消息文案有误导性。
根本原因:APP_MAX_EXECUTION_TIME 默认 1200 秒超时
文件 : init.py 第 83-86 行
python
APP_MAX_EXECUTION_TIME: PositiveInt = Field(
description="Maximum allowed execution time for the application in seconds",
default=1200,
)
关键代码: base_app_queue_manager.py 第 55-84 行
python
def listen(self):
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(stopped_by=QueueStopEvent.StopBy.USER_MANUAL),
PublishFrom.TASK_PIPELINE
)
陷阱:超时也被标记为 "Stopped by user"
listen() 方法中,无论是超时 还是用户手动停止 ,都走到同一个分支,发布 stopped_by=USER_MANUAL 的 QueueStopEvent,对应消息为 "Stopped by user."。
这意味着:
- 你的 workflow 执行了 1200 秒
APP_MAX_EXECUTION_TIME默认值也是 1200 秒- 触发了超时自动终止
- 但由于代码设计,消息显示为 "Stopped by user"
还有另一个独立超时:WORKFLOW_MAX_EXECUTION_TIME
文件 : init.py 第 784-787 行
python
WORKFLOW_MAX_EXECUTION_TIME: PositiveInt = Field(
description="Maximum execution time in seconds for a single workflow",
default=1200,
)
这个配置作用于 workflow_entry.py 第 228-229 行的 GraphEngine 的 ExecutionLimitsLayer,如果触发了会走不同的失败路径(GraphRunAbortedEvent → QueueWorkflowFailedEvent),不会显示 "Stopped by user"。
总结
| 问题 | 详情 |
|---|---|
| 显示消息 | "Stopped by user" |
| 实际原因 | APP_MAX_EXECUTION_TIME 默认 1200 秒超时 (也有可能是 WORKFLOW_MAX_EXECUTION_TIME 同时触发) |
| 代码缺陷 | 超时和手动停止共用同一个 USER_MANUAL 枚举值,无法从消息区分 |
| 验证方法 | 检查 WorkflowRun 表中 finished_at - created_at 是否 ≈ 1200 秒 |
解决方案
如果你的 workflow 确实需要超过 1200 秒的执行时间,可以通过环境变量增大超时配置:
bash
# 在 .env 中设置
APP_MAX_EXECUTION_TIME=3600 # 队列监听器超时,改为 1 小时
WORKFLOW_MAX_EXECUTION_TIME=3600 # GraphEngine 执行限制,也改为 1 小时
已完成: 分析超时与停止机制 (3/3)
Read memory
分析完成!核心结论是:
你的 workflow 执行了 1200 秒,正好触发了 APP_MAX_EXECUTION_TIME(默认 1200 秒)超时,代码自动终止了工作流,但消息却显示为 "Stopped by user"------这是代码中一个命名缺陷,超时和手动停止共用同一个枚举值。