Workflow execution hangs forever (status: running, empty runData) — reproduced across SQLite/Postgres, internal/external runner, and Queue M

问题场景

用户运行一个 89 节点的生产工作流，节点类型混合了 httpRequest、redis、if、set、merge、convertToFile，以及 2 个 LangChain 节点（openAi、lmChatOpenAi、agent，即 @n8n/n8n-nodes-langchain.agent）。通过生产 Webhook（WhatsApp Business Cloud API 形状的 JSON payload，约 800–900 字节，responseMode: onReceived）触发时，n8n 会立即返回 200 {"message":"Workflow was started"}，但该 execution 会永久卡在 status: "running"，stoppedAt 保持 NULL，runData 一直为空。该问题不是确定性的：相同 payload、相同工作流、相同环境下，有时 <1s 完成，有时卡死；在某次排查中约 4/5 的真实 payload 触发卡死，另一次 10 个并发触发 10/10 卡死，几分钟后单个触发又成功。

报错原文

Workflow execution hangs forever (status: running, empty runData) — reproduced across SQLite/Postgres, internal/external runner, and Queue Mode

status: "running"
stoppedAt: NULL
runData: {}
nodeExecutionStack still contains the Webhook trigger node, unconsumed
200 {"message":"Workflow was started"}
N8N_RUNNERS_TASK_TIMEOUT=300 (never resolved, even after 5+ minutes)

原因分析

维护者在 Issue 中给出的判断是：Webhook 已经应答、但 execution 从未被 runner 取出（dequeue），空 runData 加卡住 running 是这一现象的典型特征，怀疑是配置或环境问题，而非节点代码本身。结合提交者的排查数据，可归纳为以下几种可能原因：

• 可能是 core workflow-dispatch（工作流分发）逻辑中的调度停滞，导致 execution 没有被移交给 task runner。
• 可能与部署环境相关：提交者在 Oracle Cloud/Coolify 环境可稳定复现（当天 5 个真实 WhatsApp payload 100% 复现），而在 Hetzner/Docker Swarm 上同样工作流、同样 2.28.6 版本、同一天、同样测试协议为 4/4 正常，因此更偏向环境/配置层面。
• 可能是 Queue 模式下的 webhook 注册归属或资源竞争/节流（throttling）问题——维护者建议先确认只有一个实例持有 webhook 注册，并观察主机 CPU/内存是否被节流。不过提交者在一次 92 秒卡死窗口内每 2 秒采样 top/free/loadavg，显示 CPU 85–100% 空闲、st（steal time）始终 0.0%、load average 从 0.24 降至 0.06、10GB+ 内存空闲，说明该次卡死并非资源饥饿。
• 可能涉及 Oracle ARM64 架构相关的时序因素，但这只是提交者保留的假设，未被证明是根因。

已被直接测试并排除的假设包括：task runner 整体不可用（最小 2 节点 webhook → Code 工作流可反复正常运行）、特定 Code 节点的 JS 死循环（相同 jsCode 在最小工作流中约 50ms 完成）、Redis 连接抖动（同一 Docker 网络侧车容器连续 30 次真实 PING 全部成功且延迟正常）、以及 runner 模式差异（N8N_RUNNERS_MODE=internal 下同样复现）。

环境排查

• 确认 n8n 版本：Issue 中为 2.28.6，升级到 2.36.5 后行为无变化。
• 确认数据库：SQLite 与 PostgreSQL 17 均复现。
• 确认 task runner 模式：internal 与 external 均复现，N8N_RUNNERS_AUTH_TOKEN 设置与否都复现。
• 确认执行模式：regular（单进程）与 queue（独立 worker，Redis/Bull）均复现。
• 确认部署平台与架构：Oracle Cloud/Coolify、ARM64（Ampere A1）、Ubuntu 24.04；对照环境为 x86_64 Hetzner/Docker Swarm，未复现。
• 检查环境变量：Issue 中 Oracle 侧设置了 AUTHENTICATION_API_KEY、EVOLUTION_APIKEY、EXECUTIONS_DATA_MAX_AGE、EXECUTIONS_DATA_PRUNE、N8N_BLOCK_ENV_ACCESS_IN_NODE、N8N_EDITOR_BASE_URL、N8N_ENCRYPTION_KEY、N8N_HOST、N8N_PROTOCOL、N8N_PROXY_HOPS、N8N_RELEASE_TYPE、N8N_RUNNERS_ENABLED、WEBHOOK_URL；两侧均未显式设置 DB_TYPE。
• 检查日志：卡死时容器 stdout 与反向代理访问日志中没有任何 error、exception 或 warning。
• 检查主机资源：卡死窗口内 CPU 空闲、steal time 为 0、load 下降、内存充足。
• 检查 execution 存储：execution_entity 中创建了 status: running 的行，execution_data.data（flatted 序列化格式）中 runData 为 {}，nodeExecutionStack 仍保留未消费的 Webhook 触发节点。
• 维护者建议：用 N8N_LOG_LEVEL=debug 在主容器上观察触发节点被取出前的 dispatch stall。

解决步骤

1. 先在 Queue 模式下确认只有一个 n8n 实例持有 webhook 注册，排除多实例抢占注册导致的分发异常。
2. 观察主机是否发生 CPU/内存节流；Issue 中的采样显示该次卡死无资源饥饿，所以此项作为排除项而非主因。
3. 在主容器设置 N8N_LOG_LEVEL=debug，复现卡死并抓取触发节点被取出（picked up）之前的日志，定位 dispatch 停在哪一步。
4. 提供完整工作流与确切的全部环境变量给维护者，用于区分配置问题还是核心逻辑问题。
5. 若需要恢复系统可用性，可优先尝试 Issue 中提交者采用的方式：部署看门狗轮询超过 60s 仍为 running 的 execution，并重启 n8n 进程/容器（报告约 90s 内恢复系统）。
6. 同时在另一台无问题的环境（如 x86_64 对照机）上跑同等强度的并发压测，用于验证是否为架构/时序相关；Issue 中提交者尚未在对照环境完成同等严格的并发负载测试。

验证方法

用一个真实 payload 触发 Webhook 后，检查对应 execution 是否能在数秒内结束：status 从 running 变为 success/error，stoppedAt 不再为 NULL，runData 非空且包含触发节点输出；连续多次触发（包括并发触发）均不再出现卡死，并且 debug 日志中能看到 execution 被 runner 正常取出。

参考来源

n8n-io/n8n #36886

AI 工具推荐

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

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

了解 GamsGo AI

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