L'extraction de fichier / Chargeur de données par défaut échoue : la version API « 5.4.296 » ne correspond pas à la version du Worker « 5.3.31 » (n8n Cloud 2.25.7)

Questions
1

Décrivez le problème/l’erreur/la question

Sur mon instance n8n Cloud, tout nœud qui analyse un PDF échoue avec une erreur de non-concordance de version pdf.js. Cela affecte à la fois :

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

L’entrée est un PDF valide (une URL de Supabase Storage signée est téléchargée via un nœud HTTP Request, type MIME application/pdf, ~2,5 kB). Le binaire atteint correctement le nœud — l’échec se produit dans l’étape d’analyse du PDF elle-même.

Cela ressemble à deux versions différentes de pdf.js chargées dans la même instance (le côté « API » et le côté « Worker » sont sur des versions différentes et ne peuvent pas communiquer).

Quel est le message d’erreur (le cas échéant) ?

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

Partagez la sortie renvoyée par le dernier nœud

Le nœud défaillant (Load Document / Default Data Loader en mode Binary) retourne :

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

Informations sur votre configuration n8n

  • Version n8n : 2.25.7
  • Base de données : (gérée — n8n Cloud)
  • Paramètre n8n EXECUTIONS_PROCESS : default (géré — n8n Cloud)
  • Exécution de n8n via : n8n Cloud
  • Système d’exploitation : N/A (Cloud)

Ce que j’ai déjà essayé

  • Supprimé le nœud défaillant et l’ai recréé de zéro, puis re-connecté le workflow — même erreur (donc ce n’est pas un problème de version de nœud stockée dans le workflow).
  • Basculé l’instance entre Latest Stable et Latest Beta — l’erreur ne disparaît pas, elle se déplace simplement vers un autre workflow / nœud. Un build casse le workflow A, l’autre casse le workflow B. Ce comportement du jeu de nuit suggère fortement une non-concordance d’empaquetage pdf.js au niveau de la compilation plutôt qu’un problème par workflow.
  • Vérifié les paramètres — je n’ai aucun nœud communautaire installé (donc ce n’est pas un conflit de nœud communautaire Tesseract / OCR, qui est la cause habituelle signalée dans les fils de discussion plus anciens).

Notes / contexte

  • Parce que je suis sur n8n Cloud, je ne peux pas contrôler l’image worker ou épingler/aligner moi-même la dépendance pdf.js.
  • Cela semble lié à un fil de discussion existant signalant la même paire de version exacte : The API version "5.4.296" does not match the Worker version "5.3.31"
  • Dans ce fil, le correctif impliquait l’alignement de tous les conteneurs sur la même version, ce qu’un utilisateur Cloud ne peut pas faire — je soupçonne donc un bug d’empaquetage pdf.js dans la compilation Cloud 2.25.x.

Questions

  1. S’agit-il d’un problème connu d’empaquetage pdf.js dans la compilation Cloud 2.25.x ?
  2. Y a-t-il une version stable spécifique où les versions API et Worker pdf.js sont alignées sur laquelle je devrais épingler ?
  3. Le seul chemin fiable vers l’avant pour extraire du texte PDF est-il de le faire en dehors des nœuds pdf.js intégrés de n8n (par exemple, extraire sur mon propre backend avant d’appeler le webhook, ou via une API d’extraction externe), ou un correctif est-il attendu bientôt ?

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

2

Bonjour @sawsew467

Oui

Je crois que ce n’est pas disponible pour les utilisateurs du cloud n8n

C’est probablement oui à nouveau.

Since this is a Cloud-managed failure:

  1. Ouvrez un ticket de support via le tableau de bord n8n Cloud.
  2. Crucial : Fournissez la chaîne d’erreur exacte : The API version "5.4.296" does not match the Worker version "5.3.31".
  3. Mentionnez que vous avez déjà essayé de basculer entre Stable et Beta et que le problème persiste. Cela leur indique qu’il s’agit d’une incompatibilité de dépendance au niveau du build et non d’une erreur utilisateur, ce qui généralement remonte le ticket à l’équipe d’ingénierie plus rapidement.
3

En attendant le ticket, une solution de contournement consiste à extraire le texte en dehors du pdf.js de n8n : HTTP Request → envoyer le PDF à une API d’extraction (PDF.co, Cloudmersive, ou votre propre fonction pdf-parse v1) → alimenter le texte retourné dans Default Data Loader avec Type of Data = Text.

Puisqu’aucun rendu PDF ne se produit dans n8n, cela contourne complètement l’incompatibilité de version entre API et Worker.

4

@sawsew467 Salut Thang, c’est cool de voir un Vietnamien ici ! ^^

J’ai rencontré le même problème. C’est effectivement un bug du côté de n8n, et il a aussi été signalé sur les instances auto-hébergées, pas seulement sur Cloud. En attente d’un correctif officiel, tu peux le contourner en ajoutant deux nœuds supplémentaires pour convertir ton PDF en fichier texte brut avant de le passer à un flux de travail document/RAG :

  • Extract PDF prend ton PDF binaire (par exemple à partir de HTTP Request → fichier binaire file) et extrait le texte brut dans le champ text.

  • Convert to File transforme ensuite ce champ text en un fichier .txt propre que tu peux passer sans risque à Default Data Loader ou à n’importe quel nœud de document LangChain comme entrée texte.

De cette façon, tu contournes complètement le décalage de version API/worker pdf.js tout en gardant tout à l’intérieur de n8n.

(Au fait, c’est vraiment cool de se connecter et d’échanger avec toi, mec !)