Extract from File / Default Data Loader schlägt fehl: API-Version "5.4.296" stimmt nicht mit Worker-Version "5.3.31" überein (n8n Cloud 2.25.7)

Fragen
1

Das Problem/Fehler/die Frage beschreiben

Auf meiner n8n Cloud-Instanz schlagen alle Knoten, die eine PDF analysieren, mit einem pdf.js-Versionskonflikt-Fehler fehl. Dies betrifft beide:

  • n8n-nodes-base.extractFromFile (Operation: Extract From PDF)
  • @n8n/n8n-nodes-langchain.documentDefaultDataLoader (Type of Data = Binary)

Die Eingabe ist eine gültige PDF (eine signierte Supabase Storage URL wird über einen HTTP Request-Knoten heruntergeladen, MIME-Typ application/pdf, ~2,5 kB). Die Binärdatei erreicht den Knoten ordnungsgemäß — der Fehler tritt im PDF-Parsing-Schritt selbst auf.

Das sieht so aus, als würden zwei verschiedene Versionen von pdf.js innerhalb derselben Instanz geladen (die “API”-Seite und die “Worker”-Seite befinden sich auf verschiedenen Versionen und können nicht miteinander kommunizieren).

Welche Fehlermeldung gibt es (falls vorhanden)?

The API version "5.4.296" does not match the Worker version "5.3.31".

Ausgabe des letzten Knotens freigeben

Der fehlerhafte Knoten (Load Document / Default Data Loader im Binary-Modus) gibt Folgendes zurück:

The API version "5.4.296" does not match the Worker version "5.3.31".

Informationen zu deinem n8n-Setup

  • n8n-Version: 2.25.7
  • Datenbank: (verwaltet — n8n Cloud)
  • n8n EXECUTIONS_PROCESS-Einstellung: Standard (verwaltet — n8n Cloud)
  • n8n läuft über: n8n Cloud
  • Betriebssystem: N/A (Cloud)

Was ich bereits versucht habe

  • Den fehlerhaften Knoten gelöscht und von Grund auf neu erstellt, dann den Workflow neu verdrahtet — gleicher Fehler (also kein Problem mit der gespeicherten Knotenversion im Workflow).
  • Die Instanz zwischen Latest Stable und Latest Beta umgeschaltet — der Fehler verschwindet nicht, er verschiebt sich einfach auf einen anderen Workflow / Knoten. Ein Build bricht Workflow A, der andere bricht Workflow B. Dieses Whack-a-Mole-Verhalten deutet stark auf einen pdf.js-Verpackungs-Konflikt auf Build-Ebene hin, nicht auf ein Problem pro Workflow.
  • Einstellungen überprüft — ich habe keine Community Nodes installiert (also ist dies kein Tesseract- / OCR-Community-Node-Konflikt, der in älteren Threads üblicherweise berichtet wird).

Hinweise / Kontext

  • Da ich auf n8n Cloud bin, kann ich das Worker-Image nicht kontrollieren oder die pdf.js-Abhängigkeit selbst anheften/ausrichten.
  • Dies scheint mit einem bestehenden Thread verwandt zu sein, der über dasselbe exakte Versionspaar berichtet: The API version "5.4.296" does not match the Worker version "5.3.31"
  • In diesem Thread bestand die Lösung darin, alle Container auf die gleiche Version auszurichten, was ein Cloud-Benutzer nicht tun kann — daher vermute ich einen pdf.js-Verpackungsfehler im 2.25.x Cloud-Build.

Fragen

  1. Ist dies ein bekanntes pdf.js-Verpackungsproblem im 2.25.x Cloud-Build?
  2. Gibt es eine bestimmte stabile Version, bei der die API- und Worker-pdf.js-Versionen ausgerichtet sind, auf die ich festlegen sollte?
  3. Ist der einzige zuverlässige Weg nach vorne, PDF-Text außerhalb von n8ns integrierten pdf.js-Knoten zu extrahieren (z. B. vor dem Aufruf des Webhooks auf meinem eigenen Backend extrahieren oder über eine externe Extraktions-API), oder ist bald eine Behebung zu erwarten?

Screenshot 2026-06-13 at 23.38.20
Screenshot 2026-06-13 at 23.38.201920×1317 328 KB

2

Hallo @sawsew467

Ja

Ich glaube, das ist für n8n Cloud-Nutzer nicht verfügbar

Wahrscheinlich ja auch das.

Da dies ein von der Cloud verwalteter Fehler ist:

  1. Öffne ein Support-Ticket über das n8n Cloud Dashboard.
  2. Wichtig: Gib die genaue Fehlermeldung an: The API version "5.4.296" does not match the Worker version "5.3.31".
  3. Erwähne, dass du bereits versucht hast, zwischen Stable und Beta zu wechseln, und dass das Problem weiterhin besteht. Dies zeigt ihnen, dass es sich um eine Build-Level-Abhängigkeitskonfrontation handelt und nicht um einen Benutzerfehler, was das Ticket normalerweise schneller an das Engineering-Team eskaliert.
3

Während du auf das Ticket wartest, kannst du als Workaround Text außerhalb von n8n’s pdf.js extrahieren: HTTP Request → PDF an eine Extraction API senden (PDF.co, Cloudmersive oder deine eigene pdf-parse v1 Funktion) → den zurückgegebenen Text in den Default Data Loader mit Type of Data = Text einspeisen.

Da im n8n kein PDF-Rendering stattfindet, umgehst du damit den API/Worker-Versionkonflikt komplett.

4

@sawsew467 Hallo Thang, freut mich, einen Vietnamese hier zu sehen! ^^

Ich bin auf das gleiche Problem gestoßen. Das ist tatsächlich ein Bug auf der Seite von n8n, und er wurde auch bei selbstgehosteten Instanzen gemeldet, nicht nur in der Cloud. Während wir auf einen offiziellen Fix warten, kannst du es umgehen, indem du zwei zusätzliche Nodes hinzufügst, um dein PDF in eine Klartextdatei umzuwandeln, bevor du es in einen Document- oder RAG-Workflow einspeist:

  • Extract PDF nimmt deine binäre PDF-Datei (zum Beispiel aus HTTP Request → binary file) und extrahiert Rohtext in das Feld text.

  • Convert to File wandelt dieses text-Feld dann in eine saubere .txt-Datei um, die du sicher an Default Data Loader oder jeden LangChain-Document-Node als Texteingabe übergeben kannst.

Auf diese Weise umgehst du den pdf.js-Worker/API-Versionkonflikt vollständig, während du trotzdem alles innerhalb von n8n behältst.

(Btw, freue mich auf den Austausch mit dir, Bro!)