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) falla: la versión de API "5.4.296" no coincide con la versión de Worker "5.3.31" (n8n Cloud 2.25.7)

Preguntas
1

Describe el problema/error/pregunta

En mi instancia de n8n Cloud, cualquier nodo que analiza un PDF falla con un error de desajuste de versión de pdf.js. Esto afecta a ambos:

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

La entrada es un PDF válido (se descarga una URL firmada de Supabase Storage a través de un nodo HTTP Request, tipo MIME application/pdf, ~2.5 kB). El binario llega correctamente al nodo — el fallo ocurre dentro del paso de análisis del PDF en sí.

Esto parece ser que dos versiones diferentes de pdf.js se cargan dentro de la misma instancia (el lado “API” y el lado “Worker” están en versiones diferentes y no pueden comunicarse).

¿Cuál es el mensaje de error (si lo hay)?

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

Comparte el resultado devuelto por el último nodo

El nodo que falla (Load Document / Default Data Loader en modo Binary) devuelve:

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

Información sobre tu configuración de n8n

  • Versión de n8n: 2.25.7
  • Base de datos: (administrada — n8n Cloud)
  • Configuración EXECUTIONS_PROCESS de n8n: predeterminada (administrada — n8n Cloud)
  • Ejecutando n8n a través de: n8n Cloud
  • Sistema operativo: N/A (Cloud)

Lo que ya he intentado

  • Eliminar el nodo que falla y recrearlo desde cero, luego reconectar el flujo — mismo error (así que esto no es un problema de versión de nodo almacenada en el flujo).
  • Cambiar la instancia entre Latest Stable y Latest Beta — el error no desaparece, simplemente se mueve a un flujo/nodo diferente. Una compilación rompe el flujo A, la otra rompe el flujo B. Este comportamiento de “whack-a-mole” sugiere fuertemente un desajuste de empaquetamiento de pdf.js a nivel de compilación en lugar de un problema por flujo.
  • Verificar Configuración — no tengo nodos de comunidad instalados (así que esto no es un conflicto de nodo comunitario Tesseract/OCR, que es la causa habitual reportada en hilos más antiguos).

Notas/contexto

  • Como estoy en n8n Cloud, no puedo controlar la imagen del worker ni fijar/alinear la dependencia de pdf.js por mí mismo.
  • Esto parece estar relacionado con un hilo existente que reporta el mismo par de versiones exacto: The API version "5.4.296" does not match the Worker version "5.3.31"
  • En ese hilo la solución implicaba alinear todos los contenedores a la misma versión, lo cual no es algo que un usuario de Cloud pueda hacer — así que sospecho un error de empaquetamiento de pdf.js en la compilación 2.25.x de Cloud.

Preguntas

  1. ¿Es este un problema conocido de empaquetamiento de pdf.js en la compilación 2.25.x de Cloud?
  2. ¿Hay una versión estable específica donde las versiones de pdf.js de API y Worker estén alineadas a la que debería fijarme?
  3. ¿Es el único camino confiable hacia adelante extraer texto PDF fuera de los nodos pdf.js integrados de n8n (por ejemplo, extraer en mi propio backend antes de llamar al webhook, o a través de una API de extracción externa), o se espera una corrección pronto?

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

2

Hola @sawsew467

Sí

Creo que esto no está disponible para usuarios de n8n cloud

Lo más probable es que sí.

Ya que se trata de una falla gestionada por Cloud:

  1. Abre un ticket de soporte a través del dashboard de n8n Cloud.
  2. Crucial: Proporciona la cadena de error exacta: The API version "5.4.296" does not match the Worker version "5.3.31".
  3. Menciona que ya has intentado cambiar entre Stable y Beta y que el problema persiste. Esto les indica que se trata de una incompatibilidad de dependencias a nivel de compilación y no de un error del usuario, lo que generalmente escala el ticket al equipo de ingeniería más rápido.
3

Mientras esperas la resolución del ticket, una solución es extraer el texto fuera del pdf.js de n8n completamente: HTTP Request → envía el PDF a una API de extracción (PDF.co, Cloudmersive, o tu propia función pdf-parse v1) → alimenta el texto devuelto en Default Data Loader con Type of Data = Text.

Ya que no ocurre ninguna renderización de PDF dentro de n8n, esto evita completamente la falta de coincidencia de versiones entre API y Worker.

4

@sawsew467 ¡Hola Thang, qué alegría ver a un vietnamita por aquí! ^^

He encontrado el mismo problema. Este es efectivamente un bug del lado de n8n, y también ha sido reportado en instancias auto-hospedadas, no solo en Cloud. Mientras esperas una corrección oficial, puedes trabajar alrededor del problema añadiendo dos nodos extra para convertir tu PDF a un archivo de texto plano antes de alimentarlo en ningún flujo de documento/RAG:

  • Extract PDF toma tu PDF binario (por ejemplo de HTTP Request → binary file) y extrae el texto sin formato en el campo text.

  • Convert to File entonces convierte ese campo text en un archivo .txt limpio que puedes pasar sin problemas a Default Data Loader o a cualquier nodo de documento de LangChain como entrada de texto.

De esta forma evitas completamente el problema de incompatibilidad de versión de pdf.js worker/API mientras mantienes todo dentro de n8n.

(Por cierto, me alegra mucho conectar contigo y seguir intercambiando más, bro)