Trying a n8n workflow using Pincone Vector store - getting error 'DOMMatrix not defined'

Questions
1

Shared the workflow below. The problem seems to be in the ‘sub-node Default Data Loader’ and the error returned is:
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”
}
}

Describe the problem/error/question

What is the error message (if any)?

{

“nodes”: [
{
“parameters”: {
“dataType”: “binary”,
“loader”: “pdfLoader”,
“textSplittingMode”: “custom”,
“options”: {
“metadata”: {
“metadataValues”: [
{
“name”: “doc_source_name”,
“value”: “={{ $json.name }}”
}
]
}
}
},
“type”: “@n8n/n8n-nodes-langchain.documentDefaultDataLoader”,
“typeVersion”: 1.1,
“position”: [
0,
208
],
“id”: “94e61ba6-ff2b-451b-acdb-2ab9c95bc8bb”,
“name”: “Default Data Loader”
}
],
“connections”: {
“Default Data Loader”: {
“ai_document”: [

]
}
},
“pinData”: {},
“meta”: {
“templateCredsSetupCompleted”: true,
“instanceId”: “6b7bae030020701da6f16995313279c534f558d128bf33497924651920013cb9”
}
}

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Seems like the same issue as below.

3

Welcome @subroto !

Your error comes from the Default Data Loader using loader: "pdfLoader" under the hood, which hits a pdfjs dependency that expects browser APIs like DOMMatrix that are not available in server/Docker. This was a known bug around the pdf loader and has been fixed in recent n8n versions, so first make sure your instance is really running the latest image (pull the tag you expect and restart the container). As a workaround you can skip the PDF loader completely: add an Extract from File node before your Default Data Loader, set it to “Read Text from File”, then change the Default Data Loader Type of Data to JSON or Text and map the extracted text into it. That way the loader just works on plain text and never touches the problematic pdfjs code. If you are already on the latest version and still see DOMMatrix errors after a clean pull, it would be worth sharing your exact Docker image tag and the nodes right before the Data Loader so we can double check.

4

Thanks for your suggestions.
I was able to get around the DOMMatrix error and the workflow ran successfully. I can see the 24 items at the output side of Pinecone Vector Store
However, I don’t see my index updated at the Pincecone website. (Enclosing screenshot)

Appreciate it,

(attachments)

Screenshot 2026-06-15 at 8.11.35 PM.png
Screenshot 2026-06-15 at 8.11.35 PM.png2880×1800 399 KB

5

Glad the workaround resolved the DOMMatrix issue. For the Pinecone index not updating - a few things to verify: first, confirm the Index Name and Namespace in your Pinecone Vector Store node exactly match what you see on the Pinecone dashboard (they’re case-sensitive). Second, check your Pinecone API key is scoped to the right project/environment. Third, open the Pinecone dashboard and switch to the correct index - sometimes the default view shows a different index. If the node returned 24 items in output without errors, the upsert was likely accepted, so a namespace mismatch is the most common cause of this.

6

Greetings!
Thanks for your suggestions. Since I have only one index, and did NOT create namespace while creating the same, I used Pincecone Namespane=“default” in my n8n. However, this did not help. I am following the Pinecone documentation to create a new namespace and shall try again and will get back to you. Thanks again.

7

For Pinecone, do not test the namespace as the string default with spaces. Pinecone uses __default__ for the default namespace; if you create a custom namespace, the exact same value has to be used in the n8n Pinecone node and in the dashboard filter.

The acceptance check is no longer the Data Loader output. Run one upsert with a fixed id like test-001, then list/query that id in __default__ and in the namespace you typed. If it appears in only one place, the workflow is writing correctly and the dashboard is looking at a different namespace.

8

Issue still not resolved.

9

Since the DOMMatrix part is already bypassed and n8n shows 24 output items, I would stop using the Pinecone dashboard as the first proof point.

The next split is:

  1. n8n produced chunks but did not upsert them;
  2. Pinecone accepted the upsert but they landed in a different namespace/index/project;
  3. Pinecone accepted them, but the dashboard filter is not showing the namespace you wrote to.

The smallest proof test I would run:

  • use one tiny text input, not the PDF;
  • set a fixed id like test-001;
  • set namespace explicitly to default or to a simple custom value like n8n_test;
  • include one obvious metadata field, for example source: n8n_probe;
  • immediately run a Pinecone query/fetch for test-001 in that exact namespace.

If fetch/query finds test-001, the workflow is writing correctly and the issue is dashboard/index/namespace visibility.

If fetch/query cannot find test-001, the issue is before or during upsert: index name, project/API key scope, embedding dimension mismatch, or the vector-store node not receiving the items you think it is receiving.

I would also avoid namespace values with spaces or quotes. Test with either default or n8n_test so you remove one variable from the diagnosis.