Extração de arquivo / Carregador de dados padrão falha: versão da API "5.4.296" não corresponde à versão do Worker "5.3.31" (n8n Cloud 2.25.7)

Perguntas
1

Descreva o problema/erro/pergunta

Na minha instância n8n Cloud, qualquer nó que analisa um PDF falha com um erro de incompatibilidade de versão do pdf.js. Isso afeta ambos:

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

A entrada é um PDF válido (uma URL assinada do Supabase Storage é baixada por meio de um nó HTTP Request, tipo MIME application/pdf, ~2,5 kB). O binário chega corretamente ao nó — a falha ocorre dentro da própria etapa de análise de PDF.

Parece que duas versões diferentes do pdf.js estão sendo carregadas na mesma instância (o lado da “API” e o lado do “Worker” estão em versões diferentes e não conseguem se comunicar).

Qual é a mensagem de erro (se houver)?

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

Compartilhe a saída retornada pelo último nó

O nó que falha (Load Document / Default Data Loader no modo Binary) retorna:

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

Informações sobre sua configuração n8n

  • Versão n8n: 2.25.7
  • Banco de dados: (gerenciado — n8n Cloud)
  • Configuração n8n EXECUTIONS_PROCESS: padrão (gerenciado — n8n Cloud)
  • Executando n8n via: n8n Cloud
  • Sistema operacional: N/A (Cloud)

O que eu já tentei

  • Deletei o nó que estava falhando e recriei do zero, depois reconectei o fluxo de trabalho — mesmo erro (portanto, isso não é um problema de versão de nó armazenada no fluxo de trabalho).
  • Alternei a instância entre Latest Stable e Latest Beta — o erro não desaparece, apenas muda para um fluxo de trabalho / nó diferente. Uma compilação quebra o fluxo A, a outra quebra o fluxo B. Esse comportamento de “whack-a-mole” sugere fortemente uma incompatibilidade de empacotamento do pdf.js no nível de compilação, em vez de um problema por fluxo de trabalho.
  • Verifiquei as Configurações — não tenho nós da comunidade instalados (portanto, isso não é um conflito de nó da comunidade Tesseract / OCR, que é a causa usual relatada em tópicos antigos).

Notas / contexto

  • Como estou na n8n Cloud, não consigo controlar a imagem do worker ou fixar/alinhar a dependência do pdf.js por conta própria.
  • Isso parece estar relacionado a um tópico existente relatando o mesmo par de versões: The API version "5.4.296" does not match the Worker version "5.3.31"
  • Naquele tópico, a correção envolvia alinhar todos os contêineres para a mesma versão, o que não é algo que um usuário Cloud pode fazer — então suspeito de um bug de empacotamento do pdf.js na compilação 2.25.x do Cloud.

Perguntas

  1. Este é um problema conhecido de empacotamento do pdf.js na compilação 2.25.x do Cloud?
  2. Existe uma versão estável específica em que as versões do pdf.js da API e do Worker estão alinhadas que eu deveria fixar?
  3. O único caminho confiável para frente é extrair texto em PDF fora dos nós pdf.js integrados do n8n (por exemplo, extrair no meu próprio backend antes de chamar o webhook, ou por meio de uma API de extração externa), ou uma correção é esperada em breve?

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

2

Oi @sawsew467

Sim

Acredito que isso não está disponível para usuários da n8n cloud

Provavelmente sim novamente.

Como isso é uma falha gerenciada na Cloud:

  1. Abra um ticket de suporte via painel da n8n Cloud.
  2. Crucial: Forneça a string de erro exata: The API version "5.4.296" does not match the Worker version "5.3.31".
  3. Mencione que você já tentou alternar entre Stable e Beta e que o problema persiste. Isso indica a eles que é um incompatibilidade de dependência no nível da compilação e não um erro do usuário, o que geralmente faz o ticket ser escalado para o time de engenharia mais rapidamente.
3

Enquanto você aguarda a resolução do ticket, uma solução alternativa é extrair o texto fora do pdf.js do n8n: HTTP Request → enviar o PDF para uma API de extração (PDF.co, Cloudmersive ou sua própria função pdf-parse v1) → alimentar o texto retornado no Default Data Loader com Type of Data = Text.

Como não há renderização de PDF dentro do n8n, isso contorna completamente a incompatibilidade de versão entre API/Worker.

4

@sawsew467 Oi Thang, que legal encontrar um vietnamita por aqui! ^^

Eu encontrei o mesmo problema. De fato, é um bug do lado do n8n, e também foi reportado em instâncias auto-hospedadas, não apenas na Cloud. Enquanto espera por uma correção oficial, você pode contornar o problema adicionando dois nós extras para converter seu PDF em um arquivo de texto simples antes de alimentá-lo em qualquer workflow de documento/RAG:

  • Extract PDF recebe seu PDF binário (por exemplo de HTTP Request → binário file) e extrai o texto bruto no campo text.

  • Convert to File então transforma esse campo text em um arquivo .txt limpo que você pode passar com segurança para Default Data Loader ou qualquer nó de documento LangChain como entrada de texto.

Dessa forma você contorna completamente a incompatibilidade de versão do worker/API do pdf.js enquanto mantém tudo dentro do n8n.

(A propósito, fico muito feliz em conectar e trocar mais ideias com você!)