嗨各位！
我在隊列模式（EXECUTIONS_MODE=queue）下運行 n8n 2.21.7，搭配
PostgreSQL 和 Redis，託管在 Easypanel 上並使用 Docker。
我使用表單觸發器建立了一個工作流，responseMode 設定為
「lastNode」，後面接著 AI Agent 節點（OpenAI），最後是表單
完成節點，用來在螢幕上顯示結果。
在編輯器內手動測試工作流時，它運作完美。
但當我在生產環境中提交表單時，它立即失敗並出現此錯誤：
「Cannot read properties of undefined (reading ‘execute’)」
奇怪的是，發生錯誤時 runData 完全是空的 — 看起來它在任何節點甚至
開始執行之前就失敗了。堆疊追蹤指向 bull@4.16.4 Queue.onFailed。
我的所有其他工作流在生產環境中運行正常。這個問題似乎特定於
表單觸發器需要保持連接開啟以等待最後一個節點回應的情況。
我已經嘗試設定 N8N_RUNNERS_ENABLED=false，但錯誤仍然存在。
有人遇過這種情況嗎？有任何想法可能是什麼原因造成的嗎？
謝謝！
這個「Cannot read properties of undefined (reading ‘execute’)」的錯誤在不同的佇列模式組合中出現 — "On form submission" trigger not working using the production URL · Issue #19317 · n8n-io/n8n · GitHub 對生產環境 URL 的表單觸發器有相同的情況，Postgres Node Fails in Queue Mode: “Cannot read properties of undefined (reading ‘execute’)” · Issue #15154 · n8n-io/n8n · GitHub 在佇列模式下遇到 Postgres 的問題。#15154 被關閉並標記為「未計劃」，沒有修復，所以這是一個開放的 n8n bug，不是你那邊的問題。
值得試試的暫時解決方案：將表單觸發器的「Respond When」從「Workflow Finishes」改為「Form Is Submitted」。你會失去表單頁面上的即時結果顯示，但回應會在提交時立即返回，這樣可以避免佇列交接出現的問題。你試過嗎？
嗨 @ricardo_balako
你遇到的錯誤「Cannot read properties of undefined (reading ‘execute’)」是 n8n 隊列模式中通訊中斷的典型症狀。因為你的工作流在編輯器中運作正常，但在生產環境中失敗，問題幾乎肯定不是出在你的工作流邏輯本身，而是分散式環境處理任務的方式有問題。在隊列模式中，主要實例將任務發送給單獨的工作進程，如果該工作進程無法正確初始化所需節點，它會在開始執行前就崩潰。
最常見的原因是主要實例和工作實例之間的版本不匹配。即使兩者看起來都在運行最新版本，底層 Docker 映像中的細微差異也可能導致它們無法正確通訊。必須確保兩個服務明確使用完全相同的映像標籤，並且同時對兩個組件進行完整重新部署，以確保它們保持同步。
另一個關鍵因素是環境變數在整個基礎設施中的一致性。主要服務和工作服務必須共享完全相同的配置，特別是關於加密金鑰、資料庫連接詳細資料和 Redis 設定。如果工作進程缺少正確的配置，當它嘗試檢索開始任務所需的工作流數據時，它可能無法使用資料庫或 Redis 進行身份驗證，導致「undefined」錯誤。
你還應該驗證工作服務是否配置為專門作為工作進程運行。在你的 Easypanel 設置中，確認工作容器的命令設置為 worker（例如 n8n worker）。此外，在你的工作進程上設置環境變數 N8N_REINSTALL_MISSING_PACKAGES=true 是一個好做法，因為它確保工作進程具有所有必要的依賴項，例如 AI Agent 節點所需的依賴項，這些在全新的工作進程環境中可能缺失。
錯誤指向 bull（隊列管理庫）這一事實證實故障發生在基礎設施級別。最好的解決辦法是忽略主要的 n8n 日誌，而是在提交表單的確切時刻專注於工作容器的日誌。這些特定於工作進程的日誌通常會提供具體原因——例如連接超時或缺少依賴項——說明任務初始化失敗的原因。
如果你已驗證版本控制、配置和日誌，問題仍然存在，你可能想通過在主要實例上設置 EXECUTIONS_PROCESS=main 作為臨時診斷步驟來測試。雖然這繞過了工作進程基礎設施，但它會確認問題是否嚴格與隊列系統相關。如果工作流在這個模式下運行正常，就確認了你的問題僅限於主要 n8n 實例和工作進程之間的互動。
歡迎 @ricardo_balako！
這裡的根本原因是架構問題：Form Trigger 搭配 responseMode=lastNode 需要主要的 n8n 程序保持 HTTP 連線開啟，直到工作流程完成。在佇列模式中，執行會被轉交給 worker — 而這個開啟的連線無法跨越程序邊界追蹤它。堆疊追蹤中的 Queue.onFailed 確認了工作在佇列層級失敗，甚至在任何節點開始之前。
最快的修復方式就是 achamm 建議的 — 將「Respond When」改為「Form Is Submitted」。如果你需要將 AI 結果顯示給使用者，常見的模式是將他們重新導向到一個結果頁面，該頁面輪詢 webhook 或檢查狀態端點。
如果你真的需要 lastNode 模式，唯一乾淨的選擇是在佇列模式外執行那些特定工作流程 — 要麼在同一個實例上使用 EXECUTIONS_PROCESS=main（不建議在大規模環境中使用），要麼在沒有啟用佇列模式的獨立 n8n 實例上執行。
還有一項值得快速檢查的事項：確認你的 worker 容器版本確實是 2.21.7，且共享相同的 N8N_ENCRYPTION_KEY — 此處的不匹配會產生這個確切的故障模式。
值得確認已經提示過的內容：這是一個已知的 n8n 漏洞，涉及佇列模式中的表單/webhook 樣式觸發器，不是您工作流程中的問題。之所以在編輯器中有效是因為手動執行在主流程中運行，但在生產 URL 上失敗是因為在佇列模式中工作者會拾取它，而觸發器上下文的連接方式並不相同。
在上游修復之前的實際解決方案。如果這個工作流程不需要佇列模式的規模，請在常規（主）執行模式中運行它，並為重型工作流程保持佇列模式。如果所有內容都必須使用佇列模式，常見的解決方案是將其分割：一個純 Webhook 節點接收表單提交（在佇列模式中 webhook 的表現優於表單觸發器），然後分別處理回應，而不是依賴透過表單節點的 responseMode lastNode。
由於相關的 GitHub 問題已關閉且未計劃修復，不要等待修復。訂閱它以保持可見性，但現在就著手解決它。您具體使用的是哪個 n8n 版本，以防有值得標記的回歸視窗。
已解決！以下是對我有效的方法：
問題正是 @kjooleng 所描述的 — 我的 n8n 服務之間的版本不相容。我在 Easypanel 上執行 n8n，共有三個獨立服務：n8n_start、n8n_webhook 和 n8n_worker。它們都執行不同版本的 Docker 映像，導致隊列通訊在任何節點執行前就中斷了。
修復很簡單：我將三個服務都更新為相同的 latest 標籤，並同時重新部署所有服務。之後，一切在生產環境中都完美運行。
主要結論：如果您在隊列模式下執行 n8n，並使用獨立的 worker/webhook 容器，請確保所有服務的版本完全相同。即使主實例和 worker 之間版本有輕微差異，也足以觸發此錯誤。
感謝大家的幫助！