06. Triggers 与 Webhooks：执行从哪里开始

6.1 触发器是“创建 execution 的入口”

普通 action 节点在已有 execution 中被调用；trigger 节点负责在没有上游 item 时创建一条新的执行链。n8n 将入口拆成几类：

相关目录：packages/cli/src/webhooks、packages/cli/src/workflows/triggers、packages/core/src/execution-engine/triggers-and-pollers.ts、scheduled-task-manager.ts。

6.2 工作流激活

工作流从 inactive 变为 active 时，系统需要：

读取工作流和节点类型。
找到所有 trigger、poll、webhook 节点。
向 webhook registry 注册路径和方法。
为 schedule/poll 建立运行任务。
记录激活状态，确保重启或多主实例不会重复注册。

ActiveWorkflowManager、WebhookTriggerRegistrar 和 NonWebhookTriggerRegistrar 分担这些职责。激活不是“改一个 boolean”，而是把工作流的入口投影到多个运行时注册表。

6.3 Webhook 的两条路径

Webhook 处理至少有两种模式：

测试 URL：编辑器打开临时监听 → 请求到达 → 手动 execution → 立即反馈
生产 URL：active workflow registry → 认证/限流/解析 → execution → response mode

生产 webhook 可能同步等待最后一个节点结果，也可能立即返回并异步执行。Webhook 节点的 response mode、Respond to Webhook 节点、等待 webhook 和响应大小限制共同决定 HTTP 生命周期。不能只看 node 的 execute()，还要看：

6.4 调度与轮询

Schedule trigger 并不在节点内部 setInterval。节点 description 提供时间规则，scheduled-task-manager.ts 负责计算下一次运行，scheduler 服务负责持久化和恢复任务。Poll trigger 也有独立的 poll job manager，避免每条 execution 都拥有一个永不结束的 timer。

这个分层让实例重启后可以重新装载 active workflow，让 queue mode 下的入口和 worker 处理解耦；代价是激活、调度、重复触发和时区问题需要跨模块协调。

6.5 等待和恢复

当 workflow 运行到等待 Webhook、延迟或外部事件节点时，执行器将恢复所需信息写入执行状态并结束当前进程工作。后续请求通过 waiting-webhooks.ts、waiting-forms.ts 等模块找到执行并恢复。

running
  → save execution + resume token
  → release worker / HTTP request
  → resume request
  → load execution data
  → continue WorkflowExecute

6.6 设计取舍

入口注册表与执行器分开：Webhook 服务器可以快速接收请求，执行器可以被队列化；代价是请求上下文必须安全地序列化或通过 execution id 恢复。

durable scheduler：任务可以跨重启恢复；代价是需要处理重复调度、leader、时区和数据库锁。

同步响应可选：适合低延迟 API；代价是长工作流会占住请求连接，因此异步 response、队列和 webhook response relay 是生产部署的重要组合。

6.1 触发器是“创建 execution 的入口”​

6.2 工作流激活​

6.3 Webhook 的两条路径​

6.4 调度与轮询​

6.5 等待和恢复​

6.6 设计取舍​