n8n 批量处理遇到一条 500 会立刻停吗？40 次五条数据对照

“第一条失败就不会发送后四条”是错的

我们先写下了一个看似合理的预期：HTTP Request 节点按五条输入逐项请求，如果第一条返回 500，默认遇错停止应该只留下第一条请求；第三条失败则应该留下三条。

一轮诊断运行直接推翻了它。第一条或第三条返回 500 时，本地服务仍收到了第 1、2、3、4、5 条请求。诊断协议因此有两项断言失败。我们没有删掉这次失败，也没有把行为改写成原来的预期；而是根据服务端实际可观察的请求修正冻结协议，再从新容器执行完整实验。

正式结果是 40 次工作流、每次五条输入、共 200 条服务端请求，结构验证失败为 0。

两份工作流只改一个失败设置

实验固定 n8n 2.30.5。准备节点生成五条数据，itemId 依次为 1 到 5。HTTP 服务按场景让第 1、3、5 条返回 500，或让五条全部返回 200；服务在发送响应前先记录请求，因此工作流失败不会抹掉已经发生的调用。

两份可导入工作流的节点、输入和请求地址相同：

四种场景分别重复五次，每个策略 20 次，共 40 次执行。这里测的是一个 HTTP Request 节点接收五条输入的批次，不是五个独立节点，也不是 Split in Batches 循环。

默认停止阻断了下游，没有撤回后续请求

三个失败场景的 15 次默认执行全部标记为 error，退出码为 1，下游节点一次也没有运行。这部分符合“遇错停止”的直觉。

反直觉的是服务端记录：每次运行都收到了 itemId 1|2|3|4|5。第一条失败时，后四条并没有因为最终执行失败而消失；第三条失败时，第 4、5 条也已到达。对这个版本和节点配置，更准确的描述是：HTTP 节点完成这批输入请求后，以其中的错误决定节点和工作流状态，再阻断下游。

这对有副作用的接口很重要。批量发消息、创建工单或修改记录时，工作流显示失败不等于“失败项之后的请求没有执行”。如果人工看到红色状态后把整个批次重跑，已经成功的条目可能再次产生副作用。

继续处理让 15 次含错误执行显示成功

表格最后一列是五次运行合计，每次失败场景都有一个错误输出。继续模式的 15 次失败场景执行全部显示 success，退出码为 0，下游也全部运行，并各收到五个输出项，其中一个带错误信息。

这不是错误消失了，而是错误被转成了数据。若下游只统计“工作流成功次数”，这 15 个 HTTP 500 会完全藏在绿色状态里。生产工作流至少要显式识别错误项、记录 itemId 与响应、把失败项送入单独队列，并对失败计数设告警。

批次重跑必须按条目对账

默认停止模式下，不能根据执行失败就重放五条输入。正确做法是给每条业务数据一个稳定的操作 ID，保存服务端响应或资源 ID，并在补偿前查询哪几条已经成功。供应商支持幂等键时，键也应绑定到单条业务操作，而不是临时生成一个新的批次随机值。

继续模式下，不能把绿色执行当作零错误。下游应把成功项与错误项拆开：成功项进入正常路径，错误项保留原 itemId、状态码、响应体和执行 ID。只有错误项符合有限重试条件且副作用安全时，才进入重试。

若业务要求“一条失败后绝不能再调用后面的条目”，本实验说明不能只依赖 HTTP Request 节点的默认失败状态。需要明确的逐条控制流，在每次调用后检查结果并决定是否继续；上线前仍要用接收端日志验证，而不是根据画布连线推测顺序。

诊断失败为什么必须公开

最初的一轮只有八次执行，每个策略和场景各一次。协议假设停止模式只会请求到失败项，因此第一条和第三条失败场景各触发一次断言失败。服务端日志、n8n 输出和运行器检查一致指向同一事实：五条请求都已发送。

这不是正式结果的一部分，也不能用来估计频率。它的价值是防止我们把名称“stop on error”直接解释为网络层行为。正式协议随后把可观察问题改为：请求集合是否完整、执行状态是什么、下游是否运行、错误项是否被传递。40 次完整运行全部符合该协议。

这组结果不能外推到哪里

• 夹具在本机确定性运行，没有模拟网络延迟、并发 worker、限流或供应商重试；
• 只覆盖 n8n 2.30.5 的 HTTP Request 节点、五条输入和单个受控 500；
• 没有测试 Loop Over Items、批次子工作流或队列模式；
• 请求记录不等于真实付款、消息、库存或数据库事务；
• 五次重复用于确认固定行为，不用于估计生产故障率。

证据包包含两份工作流、40 行逐次运行记录、200 行服务端请求、八个规范化样本和汇总 JSON。复跑时应使用新的输出目录，并把供应商侧日志作为副作用是否发生的最终证据。