Google Sheets node executes both success and error outputs when connection times out

快速结论：当节点同时开启 On Error: Continue (using error output) 和 Always Output Data，且执行因连接超时等原因失败时，n8n 2.x 会先正确把错误送到 error 分支，随后“始终输出数据”逻辑只检查第一个（success）输出，发现为空便补入一个空 item，导致 success 与 error 两个分支在同一次执行中都被触发。优先排查是否同时启用了这两项设置，而不是先怀疑 Google Sheets 或凭据问题。

适用环境：Issue 中确认的环境为 n8n（Google Sheets 节点 typeVersion 4.7）；该问题已在不含 Google Sheets 节点的最小复现中重现，证明与具体节点无关，属于核心执行引擎行为。Issue 未提供操作系统、Python、CUDA、显卡等环境信息，无需针对这些项目排查。

最快修复方案：暂无确认的一步修复方案。在 n8n 2.x 上，Issue 中给出的处理方式是：若 success 分支在表格无行时不需要 item，关闭该节点的 Always Output Data；若必须保留，则在 success 分支开头加一个 IF 节点过滤空 item（条件如 {{ Object.keys($json).length > 0 }}）。

注意事项：官方说明中明确，把“仅当所有输出均为空才补空 item”的修复视为破坏性变更，因此只在 v3 中提供（PR #37055，包含于 n8n@3.0.0 预发布版），2.x 不会回移；且该修复此前曾合入（#17602）又因现有工作流依赖旧行为而回滚（#18577）。关闭 Always Output Data 会改变“无数据时仍往下传”的流程语义，升级到 v3 前也应利用 v3 的破坏性变更检测（#33553）检查所有“多输出节点 + Always Output Data”的工作流。

问题场景

用户在 n8n 中使用 Google Sheets 节点读取一个有效且含数据的表格，节点设置了 Retry on Fail、Execute Once、Always Output Data，并将 On Error 配置为 Continue Using Error Output。实际触发连接超时时，同一次节点执行同时产生了两条路径：error 输出带有超时提示，success 输出却带着一个空 item，而不是表格行数据。后续讨论用 Code 节点抛错的极简工作流复现了相同现象，说明问题不限于 Google Sheets 节点，而是发生在核心执行引擎处理失败与输出时的行为。

报错原文

Google Sheets node executes both success and error outputs when connection times out

The connection timed out, consider setting the 'Retry on Fail' option in the node settings

This is an item, but it's empty.

原因分析

按 Issue 中维护者的解释，当节点同时启用 On Error: Continue (using error output) 与 Always Output Data 时：节点失败后错误确实被路由到 error 输出，但“Always Output Data”逻辑只检查第一个输出（即 success 输出），发现其为空便追加一个占位空 item。于是 error 分支收到真实错误，success 分支收到 {}，两个分支同时执行。因此报错中的“连接超时，建议开启 Retry on Fail”只是触发失败的表面信息，即使已开启重试，只要该次执行最终失败，这一组合行为仍可能出现。

Retry on Fail 是否真正生效、重试次数与等待时间如何配置，需要结合节点设置单独确认；它不是本次“双输出”现象的直接原因。

环境排查

确认 n8n 主版本：该行为在 2.x 中存在，v3 已包含修复；可用 n8n --version 或界面版本信息核对。
确认出问题的节点是否同时设置了 On Error: Continue (using error output) 与 Always Output Data。
确认该节点是否具有多个输出：多输出 + Always Output Data 是触发条件之一，v3 的破坏性变更检测会标记此类工作流。
如使用 Google Sheets 节点，可核对节点类型、operation 与所引用表格/工作表名称，以排除配置错误，但不要因此忽略核心引擎层面的复现证据。
Issue 未涉及 Python、CUDA、PyTorch、显卡或自定义依赖版本，无需排查这些项。

解决步骤

先在不受网络与凭据影响的场景复现：新建“手动触发 → Code 节点”工作流，让 Code 节点执行 throw new Error('Simulated failure');，将 Code 节点的 On Error 设为 Continue (using error output)，打开 Always Output Data，并把 error 与 success 两个输出分别接到 No Operation 节点。若两个分支同时激活，即确认是核心引擎行为。
若 success 分支不需要空 item，关闭该节点的 Always Output Data。错误仍会进入 error 输出；success 分支只会在有真实数据行时执行。
若业务上必须保留 Always Output Data，则在 success 分支下游加入 IF 节点，以 {{ Object.keys($json).length > 0 }} 为条件过滤空 item，让后续节点只处理真实数据。
评估升级到 v3：修复通过 PR #37055 进入 n8n@3.0.0 预发布版本。升级前利用 v3 的破坏性变更检测（#33553）排查所有“多输出 + Always Output Data”的节点，确认旧依赖行为不会被改变。
若同时受连接超时影响，可在节点设置中查看 Retry on Fail 的具体参数，并结合网络与 Google API 配额情况排查；该部分与双输出问题是两件事。

验证方法

在 2.x 上应用变通方案后，重新运行原本超时或无数据的工作流：error 输出只应在发生失败时收到错误；success 输出不应再出现“This is an item, but it’s empty.”的空 item，分支流向与 On Error 配置一致。用 Code 节点最小复现时，预期只有 error 分支被激活。升级到 v3 后可用同一工作流验证：success 与 error 不再同时触发，且“Always Output Data”仅在全部输出均为空时才补空 item。