Erreur « DOMMatrix is not defined » lors de l'utilisation du Data Loader par défaut avec PDF

Questions
1

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

Lors de l’utilisation du nœud Default Data Loader pour charger un fichier binaire PDF, l’exécution échoue avec l’erreur suivante :

"errorMessage": "DOMMatrix is not defined",
"errorDescription": "DOMMatrix is not defined"

Les avertissements suivants sont également enregistrés dans le conteneur :

Warning: Cannot load "@napi-rs/canvas" package: "Error: Failed to load native binding".
Warning: Cannot polyfill `DOMMatrix`, rendering may be broken.
Warning: Cannot polyfill `ImageData`, rendering may be broken.
Warning: Cannot polyfill `Path2D`, rendering may be broken.

Étapes à suivre pour reproduire le problème

  1. Configurez un workflow avec une source PDF binaire (par exemple Google Drive, Webhook, nœud Form).
  2. Connectez la sortie binaire à un nœud Default Data Loader avec Type of Data défini sur Binary.
  3. Exécutez le workflow.

Comportement attendu

Le Default Data Loader devrait analyser correctement le PDF et transmettre le contenu en aval.

Comportement réel

Le nœud échoue avec DOMMatrix is not defined. Le package @napi-rs/canvas ne peut pas être chargé, ce qui empêche pdfjs-dist de polyfiller les API natives du navigateur requises.

Informations sur votre configuration n8n

  • Version n8n : 2.25.7 (Self Hosted)
  • Exécution de n8n via : Docker
  • Mode données binaires : filesystem

Contexte supplémentaire

Ce problème semble avoir été introduit dans la v1.98.0 lorsque pdfjs-dist a été mis à niveau vers une version qui dépend des API natives du navigateur non disponibles dans les environnements serveur Node.js. Il a été signalé par plusieurs utilisateurs dans les versions précédentes et semble persister dans la v2.25.7.

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

Veuillez partager votre workflow

Partagez le résultat renvoyé par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

Je pense que nous avons examiné exactement cela aujourd’hui.

Essaie la dernière version bêta, cela l’a résolu pour nous.

4

En attendant le test bêta @menouaw, il existe une solution de contournement fiable qui a été confirmée dans les fils de discussion connexes « DOMMatrix is not defined » : convertissez le PDF en texte avant le Default Data Loader en utilisant un nœud Extract from File (opération : « PDF ») plus tôt dans la chaîne, ce qui n’est pas suffisant en soi puisque cela emprunte le même chemin pdfjs-dist/@napi-rs/canvas.

5

Bienvenue @menouaw !

La correction de la dernière bêta est la bonne approche à long terme (suggestion de BramKn). Pour une solution temporaire en attendant de passer à la version stable : utilisez un nœud HTTP Request pour appeler une API externe de conversion PDF en texte (comme Docparser, Reducto, ou n’importe quel endpoint Tika/Unstructured auto-hébergé) à la place du Data Loader par défaut. De cette façon, votre texte PDF arrive en tant que JSON brut sans passer par le chemin pdfjs + @napi-rs/canvas qui provoque le crash. Sinon, si votre image Docker est basée sur Alpine, les liaisons natives manquantes sont généralement corrigées en passant à n8nio/n8n:latest (basé sur Debian) au lieu de la variante Alpine.