我正在以佇列模式(Redis + Worker + Database)運行 n8n,遇到一個問題,當 Redis 變得不可用時,我無法可靠地確定上一次執行的節點。
描述問題/錯誤/問題
在工作流執行期間,如果 Redis 斷開連線或重新啟動,會出現以下行為:
執行在資料庫中保持執行中狀態
UI 中看不到執行進度
Redis 恢復後,執行不會繼續或更新進度
重新啟動主 n8n 實例後,執行狀態更新為已當機
但是,UI 和執行數據沒有清楚地顯示工作流停止在哪個節點
關於您的 n8n 設置的信息
- n8n 版本:2.11.4
- 資料庫(預設值:SQLite):pgsql
- n8n EXECUTIONS_PROCESS 設置(預設值:own、main):
- 透過以下方式運行 n8n(Docker、npm、n8n cloud、desktop app):Docker
- 作業系統:
問題
- 在這種情況下,是否有任何 官方或推薦的方式 來確定上一個成功完成的節點?
嗨 @halouprogramer
你的 n8n 設置使用 Redis 作為「信使」來協調主系統和工作者之間的工作。當 Redis 斷開連接時,信使就消失了,這意味著主系統永遠不會收到任務已完成的信號。這會導致任務卡在「運行中」狀態。當你重啟系統時,n8n 會注意到任務從未正式結束,並將其標記為「已崩潰」作為清理的一種方式。
儘管任務被標記為「已崩潰」,但 n8n 通常會在進行過程中將每個單獨步驟(節點)的結果保存到你的數據庫中。問題在於 n8n 用戶界面不是設計來顯示已崩潰執行的部分進度的。這就是為什麼用戶界面看起來是空白的或沒有突出顯示工作流停止的位置,儘管數據實際上存在。
要找出確切是哪個節點最後完成的,你需要繞過用戶界面並直接查看你的 PostgreSQL 數據庫。通過在數據庫表中搜索特定的執行 ID,你可以看到該運行的原始數據。成功將其輸出保存到數據庫的最後一個節點就是工作流停止的位置。
SELECT data
FROM execution_entity
WHERE id = YOUR_EXECUTION_ID;
**注意:**在你的 Postgres 實例中運行以下查詢(將 YOUR_EXECUTION_ID 替換為實際的 ID)
要防止這種情況在將來發生,你可以調整一些設置以使你的系統更具彈性。增加 Redis 超時時間可以給 n8n 更多的時間從短暫的網絡故障中恢復,設置最大「執行超時」可以確保卡住的任務會自動關閉,而不是無限期地掛在「運行中」狀態。
歡迎加入社區 @halouprogramer!
在隊列模式下,你看到的情況不幸是預期內的:一旦 Redis 在執行中途中斷,主實例永遠不會收到來自背景工作的乾淨「我已完成」信號,所以運行會保持「運行中」狀態直到某些東西將其清理,而當它被清理時,在 UI 中會被標記為「已崩潰」,且沒有節點級別的上下文資訊。
如果你真的需要知道「這在哪裡停止了?」,基本上你有兩個選項:
除此之外,唯一真正的解決方案是保持 Redis 穩定(逾時、重新連線、基礎設施層面),因為只要「信使」可以隨時消失,n8n 就沒有可靠的方式來結束循環並用準確的最終狀態標記執行。
我會把這視為一個可觀測性和恢復設計問題,而不僅僅是 Redis 問題。對於生產工作流程,在關鍵節點周圍添加檢查點日誌,這樣即使執行 UI 只顯示崩潰,你也能判斷出哪些已完成。然後檢查隊列/工作進程重啟行為和 Redis 持久化,因為沒有檢查點的話,工作流程可能會以最糟的方式失敗:半途而廢,沒有明顯的恢復點。