saveDataSuccessExecution: ‘none’ + zero-output-item execution → execution never marked finished (stuck ‘running’ forever)

问题场景

在 n8n 中运行轮询/检查类工作流（Schedule Trigger → HTTP Request 或类似节点 → 可能返回 0 个 item 的节点，例如 Code 节点返回 []，或 Split Out 节点拆分空数组），并把工作流的 saveDataSuccessExecution 设为 “none”（或通过环境变量 EXECUTIONS_DATA_SAVE_ON_SUCCESS=none 全局继承）。当某次执行最后可达节点输出 0 个 item 时，执行在 Executions 列表里永远显示为 running。报告者用 A/B/A 对照测试确认：”none” 下 0/10 完成，”all” 下 12/12 完成；切换回 “none” 立刻复现。原生节点和 Code 节点均可复现，executionOrder v0 与 v1 均可复现，容器重启和版本升级均无效。

报错原文

saveDataSuccessExecution: 'none' + zero-output-item execution
→ execution never marked finished (stuck 'running' forever)

workflow settings: saveDataSuccessExecution = "none"
observation: 0/10 executions completed, all stuck 'running' (14+ minutes, no recovery)
A/B/A: "all" → 12/12 completed; back to "none" → 0/10 completed
API: GET /api/v1/executions/:id → 404, ?status=running → empty
row state: runData: {} (start-snapshot only)

原因分析

根据 Issue 中维护者的定位（在 master@8bff5da、master@37799ad2f 上复核）：当 saveDataSuccessExecution 为 “none” 时，一次已结束的成功生产执行会跳过 hookFunctionsSave 中的保存路径，转而交给 ExecutionPersistence.deleteInFlightExecution() 处理（execution-lifecycle-hooks.ts 中常规模式与 scaling 模式两处）。该删除调用只传 workflowId / executionId / storedAt，不传入任何终态（status / finished / stoppedAt）。行记录因此从未写入“完成”本应写入的状态，始终保持 running。开启 pruning 时只会写入一个回填的 deletedAt，同样不记录终态。

另外，卡住的行对公共 API 不可见：GET /api/v1/executions/:id 返回 404，?status=running 列表为空，UI 可见但 API 看不到，容易让人误以为是两个独立问题。executionTimeout 在该场景下未被强制执行，可能是另一个独立问题。

环境排查

• 确认 n8n 版本：已在 2.32.5、2.39.4、2.40.5、2.42.7 复现；升级版本不能解决。
• 确认 saveDataSuccessExecution 的实际来源：工作流内显式设置，还是从全局环境变量 EXECUTIONS_DATA_SAVE_ON_SUCCESS=none 继承。后者会影响所有未显式覆盖该值的工作流。
• 确认执行模式（regular / scaling）与 task runner 类型（internal JS task runner）；本 Issue 均在此环境下复现。
• 确认数据库类型：SQLite 与 Postgres 16 均已复现。
• 确认触发执行的最后一个节点是否输出了 0 个 item（例如 Split Out 空数组、Code 返回 []、Update 节点匹配 0 行）。
• 已排除（与问题无关）：task runner 健康/重启、saveExecutionProgress 设置、executionOrder v0/v1。

解决步骤

1. 在被卡住的工作流中，将 saveDataSuccessExecution 显式设置为 "all"（备选：任意非 "none" 的值，如 "error"）。Issue 中原报告者与第二位确认者均以此作为已验证的绕过方案。
2. 若使用全局环境变量 EXECUTIONS_DATA_SAVE_ON_SUCCESS=none，需要逐个在受影响工作流上显式覆盖 saveDataSuccessExecution 为 "all"；第二位报告者在 5 个受影响工作流上这样处理后，均在一个调度周期内首次成功完成。
3. 保存/激活工作流，等待下一次调度触发，观察 Executions 列表中的状态是否转为 success。
4. 排查卡住的行时，注意公共 API 会返回 404 且不出现在 ?status=running 中，不要仅凭 API 结果判断“没有运行中的执行”；以工作流 UI 的 Executions 列表为准。
5. 关注 PR #38552（“finalize unsaved executions before deletion”，@mayanksingh-27）：它会在删除路径中传入 status / finished / stoppedAt（常规与 scaling 模式），加上带保护的更新以保留已取消状态，并为 0 输出场景补充回归测试。该 PR 检查时仍未合入已发布版本；合入升级后可考虑恢复 “none” 配置。

验证方法

把 saveDataSuccessExecution 改为 “all” 后，让能够返回 0 个 item 分支的工作流运行若干次，确认 Executions 列表中每次执行都结束为 success，且不再出现长期 running 的记录。可对照 Issue 中的 A/B/A 方式：切回 “none” 应能立即复现挂起，切回 “all” 应恢复正常，以此确认改动确实生效。修复版本发布后，注意 Issue 指出的 API 与 UI 状态不一致，应以 UI 状态加 0 输出用例的回归通过作为最终确认。

参考来源

n8n-io/n8n #38551（含维护者对 #38552 的定位与两轮 master 复核、第二位自托管实例的 A/B 确认）

AI 工具推荐

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

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

了解 GamsGo AI

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