工作流程在同一 PDF 檔案上間歇性當機並變為無效（n8n Cloud、Starter 方案）

問題
,
1

描述問題/錯誤/提問

我的工作流程處理 PDF 檔案（下載 → 透過「從檔案提取」節點提取文字 → 進一步處理）。它間歇性運行：完全相同的 PDF 檔案有時會成功完成，有時會失敗，工作流程和檔案本身都沒有任何變化。
當它失敗時，工作流程之後也會被停用，儘管我從未手動關閉它 - 在崩潰之前它已發佈/啟用。
我使用的是 n8n Cloud，Starter 方案（按年計費）。

錯誤訊息是什麼（如果有的話）？

UI 中沒有顯示明確的錯誤訊息。執行只是停止了 - 執行資料中的 “lastNodeExecuted” 顯示的是「從檔案提取」之前的節點（我們的「下載檔案」節點），該點之後的所有節點都顯示 “isArtificialRecoveredEventItem”: true，這意味著 n8n 是重建它們而不是實際運行它們。這些失敗運行的總執行時間非常短（不到 ~5 秒）。

請分享你的工作流程

分享最後一個節點返回的輸出

沒有正常輸出 - 執行在中途停止。最後真正執行的節點是「下載檔案」；之後的一切都是人工恢復/空項目，不是真實輸出。

關於你的 n8n 設置的資訊

  • n8n 版本： 版本 2.29.8
  • 資料庫（預設：SQLite）： n8n Cloud 託管（非自行託管，因此預設 SQLite 不適用）
  • n8n EXECUTIONS_PROCESS 設定（預設：own, main）： N/A - 由 n8n Cloud 託管
  • 透過以下方式運行 n8n（Docker、npm、n8n cloud、桌面應用）： n8n Cloud（Starter 方案，按年計費）
  • 作業系統： N/A - 雲端託管
2

嗨 @zyll

根據你描述的症狀，這不是標準的「節點錯誤」，而是流程級別的崩潰（可能是記憶體不足 / OOM 事件）。

如果你在迴圈中處理多個檔案，請勿在一個「批次」中處理所有檔案。

  • 使用Split In Batches 節點逐個處理 PDF。
  • 確保檔案之間有小延遲（Wait 節點），以便系統進行垃圾回收。

由於你使用的是 n8n Cloud，無法手動更改 NODE_OPTIONS=--max-old-space-size。但是，你可以：

  • 檢查並行執行：進入設定並確保你未同時執行過多工作流程。
  • 最佳化 PDF：如果 PDF 特別大或包含高解析度影像，在提取時會消耗更多 RAM，即使你只想要文本。

如果「Extract From File」節點繼續崩潰，它使用的內部庫可能對 Starter 方案的 RAM 來說太重。考慮使用外部 API 進行 PDF 提取：

  • OCR.space 或 Adobe PDF Services API：這些會將記憶體負擔從你的 n8n 執行個體轉移到外部伺服器。
  • 先轉換為文本：如果可能，讓來源系統提供 .txt 或 .json 檔案而不是 .pdf。

由於你的工作流程自動被停用，這是一個基礎設施層級的事件。我強烈建議向 n8n Cloud 開設支援工單。提供他們：

  • 失敗執行的執行 ID。
  • isArtificialRecoveredEventItem: true 的提及。
  • 工作流程被自動停用的事實。

他們可以檢查後端日誌（你在 Cloud 上無法看到），以確認是否為 SIGKILL（OOM）或 PDF 解析庫中的特定分段故障。

3

嗨 @zyll 歡迎！
自動停用是 n8n Cloud 的預期行為，不是設定問題：流程級崩潰（OOM/SIGKILL，或 PDF 解析器中的原生崩潰）會觸發意圖安全停用，而且因為它是硬體崩潰而不是節點錯誤，所以也會繞過您的錯誤工作流程，這就是為什麼沒有任何內容被保存，也不會觸發警報。在 Cloud 上沒有工作流程級別的設定可以關閉此功能。由於崩潰不會觸發錯誤工作流程，而且稽核日誌串流僅限企業版，Starter 可行的方法是從外部排程器輪詢工作流程的活動狀態，並透過 n8n API 重新啟動它，這也可以將其保持在執行配額之外。
請參閱以下內容：

4

kjooleng 的 OOM 讀數是對的，但你自己的細節（間歇性的、在同一個文件上）實際上大大縮小了範圍，因為一個簡單太大的文件每次都會失敗，而不是有時失敗。相同的輸入只是偶爾失敗是並發耦合內存的特徵：那個 PDF 的提取只有在碰巧與其他執行一起運行時才會將實例推過 Starter 計劃的 RAM 上限。在安靜的時刻它能適配，在繁忙的時刻同一個文件會 OOM。這就是為什麼它看起來是隨機的，也就是為什麼「優化 PDF」不會完全解決它。變數不是文件，而是在同一時刻還有什麼在運行。

由此產生兩個問題。首先，限制此工作流的並發性，使其無法重疊重型運行。在 Cloud 上，實用的杠桿是確保 PDF 路徑無法並行觸發多次（在其前面設置一個門或隊列），因此峰值內存是一個文件的大小而不是三個。其次，當只有一個文件時，這是一個比分割成批次更大的內存杠桿：盡早丟棄二進制。「從文件提取」將整個 PDF 作為二進制加載到項目中，如果該二進制字段在下游節點中被帶動，副本會在每一步中保留，你的峰值會倍增。提取文本，然後立即設置或僅選擇文本字段，以便二進制不被拖帶。單單這一點通常就足以讓邊界文件保持在上限以下。

關於自動取消發布是有意的安全行為，這是真的，但值得將行為與後果分開：知道 n8n 在重複崩潰後停用並不能幫助你發現它發生了。一旦工作流不活躍，就不會創建執行，所以錯誤觸發器永遠不會觸發，因為沒有什麼可以附加錯誤到，你從缺少輸出而不是從警報中了解它。所以即使在內存修復之後，也要添加外部心跳：讓工作流在每次成功運行時向健康監測器（Healthchecks.io 或只是某處的時間戳行）發 ping，並在預期運行不到達時發出警報。這將「自上週二以來無聲停用」變為「在幾分鐘內發出警報」，在文檔管道上，這是實際上會使你付出代價的故障。

5

記錄成功和失敗的執行中的檔案大小、頁面數和節點記憶體使用情況。如果同一個 PDF 只是間歇性失敗，執行數據可能會顯示資源限制或超時，而不是內容不良。

6

除了限制並行數外，試試將「從檔案提取」移到透過「執行工作流程」呼叫的子工作流程中。父工作流程只保留小型 JSON 結果，二進制檔案會在子執行結束時釋放，而不會隨著每個下游節點的輸入一起傳遞——正是這種輸入傳遞導致記憶體實際成倍增加。

由於 Cloud 在硬體崩潰時會停用並跳過你的錯誤工作流程，請添加一個排程的監控程序，透過公開 API 讀取活動狀態並重新啟用以及發送警報。否則你首先會發現的就是它已經關閉了三天。

7

@colemaffeo6 為第二個症狀命名了正確的形式——一個排程看門狗，在公開 API 上讀取活動狀態。我幾天前為我自己的實例建立了這個，所以這是一個能運作的東西，而不是某個東西的描述。

為什麼那一半值得費力工具化：硬當機會在「錯誤工作流程」能執行前殺掉程序，所以應該告訴你的唯一機制就是無法運作的那個。而自動停用是正確的行為——它阻止當機迴圈——只是它是無聲的，而無聲與運作無異。

運作方式：

  1. snapshot 記錄目前哪些工作流程是活躍的——那就成了預期集合。
  2. check 取得即時狀態，如果任何一個不再活躍，就退出代碼 1。
  3. Cron 執行 check，而退出代碼驅動你已經有的任何警示——Healthchecks.io、curl 到你自己的 webhook，任何讀取狀態的東西。

在建立它時我改變主意的一件事：我留下了重新啟用。在記憶體殺死後將工作流程翻轉回來會執行相同檔案到相同天花板，所以在糟糕的一天你會得到一個閃爍的工作流程和一個更安靜的相同中斷版本。它改為計算掉落，一旦某個掉落過幾次就會說出來，因為此時答案是並發設定檔，而不是開關。如果你的當機很罕見且與負載無關，重新啟用是更好的權衡，而且它是一個短函數可以新增。

它在哪裡壞掉：你的輪詢間隔是你的盲點窗口，所以每五分鐘檢查一次意味著在任何人知道之前最多五分鐘什麼都沒有收集。而且它無法區分當機和你刻意關閉某些東西——在任何刻意變更後重新執行 snapshot，否則它會因為你自己的編輯而呼叫你。

僅標準庫。需要來自「設定」>「n8n API」的 API 金鑰；公開 API 在免費試用上不可用，所以那裡的 401 通常是計畫而不是金鑰。

8

不是修復崩潰本身的方法，但可能有助於你發現其他暴露的問題——
將匯出的工作流程 JSON 放入這個掃描器，它會標記具有 continueRegularOutput、缺少錯誤分支、沒有重試/逾時、
未認證 webhook、硬編碼認證資訊的節點。

鑑於 lastNodeExecuted 在崩潰點之前停止，值得檢查
該節點的錯誤處理是否在靜默吞下失敗。

瀏覽器本機運行，無需登入，無需上傳。

9

感谢大家的帮助，现在可以正常工作了