Extract from File / Default Data Loader fails: API version "5.4.296" does not match Worker version "5.3.31" (n8n Cloud 2.25.7)

Questions
1

Describe the problem/error/question

On my n8n Cloud instance, any node that parses a PDF fails with a pdf.js version mismatch error. This affects both:

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

The input is a valid PDF (a signed Supabase Storage URL is downloaded via an HTTP Request node, MIME type application/pdf, ~2.5 kB). The binary reaches the node correctly — the failure happens inside the PDF parsing step itself.

This looks like two different versions of pdf.js being loaded within the same instance (the “API” side and the “Worker” side are on different versions and can’t communicate).

What is the error message (if any)?

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

Share the output returned by the last node

The failing node (Load Document / Default Data Loader in Binary mode) returns:

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

Information on your n8n setup

  • n8n version: 2.25.7
  • Database: (managed — n8n Cloud)
  • n8n EXECUTIONS_PROCESS setting: default (managed — n8n Cloud)
  • Running n8n via: n8n Cloud
  • Operating system: N/A (Cloud)

What I have already tried

  • Deleted the failing node and recreated it from scratch, then re-wired the workflow — same error (so this is not a stored node-version issue in the workflow).
  • Switched the instance between Latest Stable and Latest Beta — the error does not go away, it just moves to a different workflow / node. One build breaks workflow A, the other build breaks workflow B. This whack-a-mole behavior strongly suggests a pdf.js packaging mismatch at the build level rather than a per-workflow problem.
  • Checked Settings — I have no community nodes installed (so this is not a Tesseract / OCR community-node conflict, which is the usual cause reported in older threads).

Notes / context

  • Because I am on n8n Cloud, I cannot control the worker image or pin/align the pdf.js dependency myself.
  • This appears related to an existing thread reporting the same exact version pair: The API version "5.4.296" does not match the Worker version "5.3.31"
  • In that thread the fix involved aligning all containers to the same version, which is not something a Cloud user can do — so I suspect a pdf.js packaging bug in the 2.25.x Cloud build.

Questions

  1. Is this a known pdf.js packaging issue in the 2.25.x Cloud build?
  2. Is there a specific stable version where the API and Worker pdf.js versions are aligned that I should pin to?
  3. Is the only reliable path forward to extract PDF text outside of n8n’s built-in pdf.js nodes (e.g. extract on my own backend before calling the webhook, or via an external extraction API), or is a fix expected soon?

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

2

Hi @sawsew467

Yes

I believe this is not available to n8n cloud users

Likely a yes again.

Since this is a Cloud-managed failure:

  1. Open a support ticket via the n8n Cloud dashboard.
  2. Crucial: Provide the exact error string: The API version "5.4.296" does not match the Worker version "5.3.31".
  3. Mention that you have already tried switching between Stable and Beta and that the issue persists. This tells them it is a build-level dependency mismatch and not a user error, which usually escalates the ticket to the engineering team faster.
3

While you wait on the ticket, workaround is to extract text outside n8n’s pdf.js entirely: HTTP Request → send PDF to an extraction API (PDF.co, Cloudmersive, or your own pdf-parse v1 function) → feed the returned text into Default Data Loader with Type of Data = Text.

Since no PDF rendering happens inside n8n, this sidesteps the API/Worker version mismatch completely.

4

@sawsew467 Hi Thang, nice to see a Vietnamese here! ^^

I have met the same issue. This is indeed a bug on n8n’s side, and it has also been reported on self‑hosted instances, not just Cloud. While waiting for an official fix, you can work around it by adding two extra nodes to convert your PDF into a plain text file before feeding it into any document/RAG workflow:

  • Extract PDF takes your binary PDF (for example from HTTP Request → binary file) and extracts raw text into the text field.

  • Convert to File then turns that text field into a clean .txt file that you can safely pass into Default Data Loader or any LangChain document node as text input.

This way you fully bypass the pdf.js worker/API version mismatch while still keeping everything inside n8n.

(Btw, rất vui được kết nối và trao đổi thêm với bro nhé)