n8n 长任务先响应，避免超时重试

这是我公开分享如何在生产环境中运行 n8n LLM 工作流的系列文章之一。这里的所有内容，都来自我实际销售并提供支持的一个模板——错误是我犯的，修复方案也都经过了测试。

那些没人重复下单的重复订单

三周前，我收到了一条最不想看到的消息：“嘿，同一个订单通知，我们收到了三次。”

出问题的是我自己的订单处理 webhook。商店发送订单事件 → 我的 n8n webhook 接收事件 → 工作流校验订单、调用 LLM 生成履约摘要、向数据库写入记录，再发送确认邮件。整个流程从头到尾，需要实打实地执行 60–90 秒。

问题在于：发送方的超时时间是 30 秒，而我的工作流要到 90 秒后才响应。于是，发送方做了发送方通常会做的事——重试，而且重试了两次。三次“处理成功”的执行，发出了三封确认邮件，还为同一个订单写入了三条数据库记录。

我的 sweeper 模式（这个系列里介绍过）让每一步操作都具备幂等性，因此没有人被重复扣款。但发送方看到的始终是失败。他们的仪表盘一片红，我的工作流执行记录却一片绿。执行全绿，合作方却很生气。这就是陷阱。

在 n8n 的默认设置下，Webhook 节点会收集整个工作流的输出，再将其作为 HTTP 响应返回。这意味着，HTTP 连接会在整个工作流执行期间一直保持打开——每一次 LLM 调用、每一次 API 等待、每一次数据库写入，都算在内。

自托管 n8n 会在 webhook 连接空闲约 120 秒后将其关闭。Cloud 也有类似限制。但现实中的发送方，耐心远没有这么好：

• Stripe 会在自己的超时窗口结束后重试。
• Meta/TikTok 会对 webhook 事件进行验证和重试。
• 许多 SaaS 应用在等待 10–30 秒后就会放弃，并再次发送同一个事件。

你控制不了发送方的超时时间。你唯一能控制的，是自己响应得有多快。我之前一直在设法让工作流尽快执行完毕，实际上需要的却是尽快响应。

修复方法：先响应，再干活

这次修改大约花了十分钟。思路一句话就能说清：webhook 的唯一职责是确认收到事件；真正的处理工作，在响应发出之后再做。

在 n8n 中，有两种实现方式：

方案 A——将 Webhook 节点设置为收到请求时响应，即 "When Received"（或立即响应）。响应发出后，工作流会继续运行。较新的 n8n 版本允许直接在节点上选择响应模式。

方案 B——在触发器后面紧接着放一个 "Respond to Webhook" 节点。我用的是这个方案，因为它表达得很明确。现在，我的流程是这样的：

Webhook Trigger
  → Respond to Webhook (200, {"received": true, "event_id": "{{ $json.id }}"})
  → Dedupe check (have I seen this event_id? skip if yes)
  → ... all the slow LLM/database/email work ...

响应会在一秒内发出。发送方满意了，工作流则继续在后台异步执行。

我的 webhook 响应时间 p95 从约 70 秒降到了约 400 毫秒。发送方的重试次数降到了零——因为在发送方看来，根本没有发生过需要重试的失败。

有两件事绝对不能省

快速响应只解决了一半问题。它也带来了两项必须履行的责任：

1. 幂等性现在是必需项，不再是可选项。 当你在实际处理之前就返回响应时，就无法区分“发送方因为超时而重试”和“发送方把同一个事件发送了两次”。用发送方的事件 ID 作为去重键，并在执行任何操作之前检查它。我在这个系列中介绍过自己的去重 / sweeper 模式——核心思路是：如果已处理事件表中已经存在这个 event_id，就跳过所有操作，返回已存储的结果。

2. 你必须知道后台任务什么时候失败了。 采用先响应的模式后，发送方再也不会告诉你出了问题——因为你已经告诉对方一切正常。所以，工作流后续的处理部分需要独立的错误报告机制：通过一个 Error Trigger 工作流，把 event_id 和失败的节点发给我，通知渠道是邮件加一条 Slack 消息。这就是我上周写过的“静默失败”监控——HTTP 响应是绿的，不代表最终结果也是绿的。

把这两方面合起来，就是：快速确认接收 + 基于 event_id 去重 + 独立的错误报告。少了任何一项，你都只是把故障挪到了一个更难发现的地方。

我现在为每个新 webhook 执行的检查清单

在交付任何 n8n webhook 接收端之前，我都会检查：

• 响应在 1 秒内发出（将 Respond to Webhook 紧接在触发器后面）。
• 在产生任何副作用之前，先根据发送方的 event_id 去重。
• 将 Error Trigger 工作流连接到实际处理业务的工作流，直接向我报告错误。
• 准备一个对账查询，列出“已接收但未完成”的事件（我的 sweeper 会捕获这些事件）。
• 响应体中包含 event_id，方便发送方和我关联同一个事件。

这套做法很朴素，但管用。发送方不再重试，我的执行历史也不再向合作方呈现误导性的成功记录。

我正在构建 AI Automation Lab，提供可直接用于生产环境的 n8n 工作流模板。免费的 AI Hook Generator 展示了我如何组织真实的工作流；我的开源模板位于 github.com/zhp910318/n8n-ai-automation-lab。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。