Partage du workflow ci-dessous. Le problème semble se situer dans le « sub-node Default Data Loader » et l’erreur retournée est :
Encountered error:
{
“errorMessage”: “DOMMatrix is not defined”,
“errorDescription”: “DOMMatrix is not defined”,
“errorDetails”: {},
“n8nDetails”: {
“time”: “6/15/2026, 5:38:18 PM”,
“n8nVersion”: “2.25.7 (Self Hosted)”,
“binaryDataMode”: “filesystem”
}
}
Votre erreur provient du Data Loader par défaut qui utilise loader: "pdfLoader" en arrière-plan, ce qui déclenche une dépendance pdfjs qui s’attend à des APIs de navigateur comme DOMMatrix qui ne sont pas disponibles sur serveur/Docker. C’était un bug connu concernant le chargeur PDF et il a été corrigé dans les versions récentes de n8n, donc vérifiez d’abord que votre instance exécute vraiment la dernière image (récupérez le tag attendu et redémarrez le conteneur). En tant que contournement, vous pouvez ignorer complètement le chargeur PDF : ajoutez un nœud Extract from File avant votre Data Loader par défaut, réglez-le sur « Read Text from File », puis changez le Type de données du Data Loader par défaut en JSON ou Text et mappez le texte extrait dedans. De cette façon, le chargeur fonctionne uniquement sur du texte brut et ne touche jamais au code pdfjs problématique. Si vous êtes déjà sur la dernière version et que vous voyez toujours des erreurs DOMMatrix après une récupération propre, il serait judicieux de partager votre tag d’image Docker exact et les nœuds juste avant le Data Loader pour que nous puissions vérifier.
Merci pour vos suggestions.
J’ai réussi à contourner l’erreur DOMMatrix et le workflow s’est exécuté avec succès. Je peux voir les 24 éléments au niveau de la sortie de Pinecone Vector Store
Cependant, je ne vois pas mon index mis à jour sur le site Pinecone. (Capture d’écran ci-jointe)
Ravi que la solution de contournement ait résolu le problème DOMMatrix. Pour l’index Pinecone qui ne se met pas à jour - quelques points à vérifier : d’abord, confirmez que le nom d’index et l’espace de noms (Namespace) dans votre nœud Pinecone Vector Store correspondent exactement à ce que vous voyez sur le tableau de bord Pinecone (la casse est importante). Deuxièmement, vérifiez que votre clé API Pinecone a les bonnes permissions pour le projet/l’environnement approprié. Troisièmement, ouvrez le tableau de bord Pinecone et basculez vers l’index correct - parfois la vue par défaut affiche un index différent. Si le nœud a renvoyé 24 éléments en sortie sans erreurs, l’upsert a probablement été accepté, donc une discordance d’espace de noms est la cause la plus courante de ce problème.
Bonjour !
Merci pour vos suggestions. Puisque je n’ai qu’un seul index et que je n’ai PAS créé d’espace de noms lors de sa création, j’ai utilisé Pinecone Namespace=“default” dans mon n8n. Cependant, cela n’a pas aidé. Je suis la documentation de Pinecone pour créer un nouvel espace de noms et j’essayerai à nouveau et je vous recontacterai. Merci encore.
Pour Pinecone, ne testez pas l’espace de noms en tant que chaîne default avec des espaces. Pinecone utilise __default__ pour l’espace de noms par défaut ; si vous créez un espace de noms personnalisé, la valeur exacte doit être utilisée dans le nœud Pinecone d’n8n et dans le filtre du tableau de bord.
La vérification d’acceptation n’est plus la sortie du Data Loader. Exécutez un upsert avec un identifiant fixe comme test-001, puis listez/interrogez cet identifiant dans __default__ et dans l’espace de noms que vous avez saisi. S’il n’apparaît qu’à un seul endroit, le workflow écrit correctement et le tableau de bord consulte un espace de noms différent.
Puisque la partie DOMMatrix est déjà contournée et que n8n affiche 24 éléments de sortie, j’arrêterais d’utiliser le tableau de bord Pinecone comme premier point de preuve.
La prochaine division est :
n8n a produit des chunks mais ne les a pas uploadés ;
Pinecone a accepté l’upsert mais ils se sont retrouvés dans un namespace/index/projet différent ;
Pinecone les a acceptés, mais le filtre du tableau de bord n’affiche pas le namespace auquel vous avez écrit.
Le plus petit test de preuve que je lancerais :
utiliser une toute petite entrée de texte, pas le PDF ;
définir un ID fixe comme test-001 ;
définir explicitement le namespace sur default ou sur une simple valeur personnalisée comme n8n_test ;
inclure un champ de métadonnées évident, par exemple source: n8n_probe ;
exécuter immédiatement une requête/récupération Pinecone pour test-001 dans ce namespace exact.
Si fetch/query trouve test-001, le workflow écrit correctement et le problème est la visibilité du tableau de bord/index/namespace.
Si fetch/query ne trouve pas test-001, le problème est avant ou pendant l’upsert : nom d’index, portée du projet/clé API, décalage de dimension d’embedding, ou le nœud vector-store ne reçoit pas les éléments que vous pensez qu’il reçoit.
J’éviterais également les valeurs de namespace avec des espaces ou des guillemets. Testez avec soit default soit n8n_test pour supprimer une variable du diagnostic.
