The API version “5.4.296” does not match the Worker version “5.3.31”…i am getting this error,i tried on both sefl host and cloud
Hi Team , i am getting the above error
Describe the problem/error/question
The API version “5.4.296” does not match the Worker version “5.3.31”…i am getting this error,i tried on both sefl host and cloud
What is the error message (if any)?
The API version “5.4.296” does not match the Worker version “5.3.31”…i am getting this error,i tried on both sefl host and cloud
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Share the output returned by the last node
Information on your n8n setup
- n8n version: latest
- Database (default: SQLite): pinecoine
- n8n EXECUTIONS_PROCESS setting (default: own, main): own
- Running n8n via (Docker, npm, n8n cloud, desktop app): docker
- Operating system:windows 11
Hi @Sameer_Kalkeri
First, it is important to know that this error isn’t actually a problem with your overall n8n installation or your server. Instead, it is a conflict happening inside a specific “mini-tool” that n8n uses to read and process PDF files. This tool is like a translator that helps n8n understand the contents of a PDF document.
The problem occurs because two different parts of your system are using different versions of this PDF tool. Usually, n8n has its own built-in version, but if you have installed a “Community Node” (like Tesseract for OCR), that add-on often brings its own newer version. When n8n tries to process a file, these two versions clash, and the system gets confused.
The technical terms “API version” and “Worker version” essentially refer to a manager and a worker. Imagine a manager giving instructions in one language (Version 5.4) but the worker only understands a slightly older language (Version 5.3). Because they aren’t speaking the exact same version of the language, they cannot communicate, and the process crashes.
To fix this, the easiest solution is to look for any community-installed nodes related to PDF or OCR, specifically the Tesseract node. If you have Tesseract installed, try downgrading it to version 1.3.0. This older version doesn’t use the conflicting PDF tool, which removes the clash and allows your workflow to run smoothly again.
In your specific case, since you are downloading files from Google Drive and sending them to a Vector Store, you are likely processing PDFs. Because this conflict happens globally across your n8n instance, even if you aren’t using the Tesseract node in this specific workflow, having it installed anywhere on your account can trigger this error.
Does that help?
hi @Sameer_Kalkeri
according to github, this error was covered in release 2.23.4, what is your current version?
after confirming the stable version, don’t use the Beta, unpublish, deactivate the nodes, activate again and publish. please get back to us with the answer.
dont have any tesseract installed.. and i tried on both cloud and self hosted one
already done that i have tried on both self hosted and cloud still getiing same error
perfect @Sameer_Kalkeri
please share your workflow, copy and paste it here without the sensitive data.
@Sameer_Kalkeri
Please click on each node with the red symbol and send a photo of each one
@Sameer_Kalkeri
thank you for sharing!
update all services to the same image, restart all docker containers docker compose pull docker compose up -d, and confirm that they are all the same version docker compose ps
docker exec -it <container_n8n> n8n --version
docker exec -it <container_worker> n8n --version
Default Data Loader node documentation | n8n Docs
let us know if it works.
Thank you, restarted it…it worked.. now getting dommatrix error.
@Sameer_Kalkeri this is a bug in the library that reads PDFs in the Node.js/self-hosted environment.
@Sameer_Kalkeri
use n8n version 1.100.1
why should i downgrade it?
it will impact my other workflows
This error is a version mismatch between your n8n components in queue mode, the main process is on 5.4.296 and a worker is on 5.3.31. In queue mode the main instance, the workers, and any webhook processors all have to run the exact same n8n version, and here one of them did not get upgraded with the rest.
Fix: make every container run the same image tag. If you pinned a version in your compose file, bump all of them together (main and workers) and recreate, or if you are on :latest, the usual cause is that one container pulled a newer image than another, so docker compose pull then docker compose up -d --force-recreate across the whole stack so they all land on the same build. After restart, confirm both report the same version.
The thing to avoid going forward: pin an explicit version tag on all components rather than :latest, so a partial pull cannot leave your workers a version behind your main process. Mismatches like this can cause executions to behave inconsistently or fail in confusing ways, so it is worth getting them locked to the same version. Are you on Docker compose, and did you recently upgrade only part of the stack?
