AI Agent + Code node OOM crash con ~1-2MB binary en Cloud Starter — punto de crash no determinista, cero crashes en self-hosted

Preguntas
,
1

Resumen

Estoy experimentando fallos por falta de memoria (OOM) reproducibles en n8n Cloud Starter con cargas muy pequeñas (~1-2 MB binarios). El punto de fallo fluctúa entre el nodo Code y el AI Agent entre ejecuciones con la misma entrada, lo que sugiere fuertemente una fluctuación de recursos de trabajador compartido en lugar de un error en el código del usuario.

El mismo workflow JSON funciona perfectamente en self-hosted (Docker, 8 GB en el host) — 30+ ejecuciones sin ningún fallo.

Entorno

  • Plan: Cloud Starter
  • Instancia: verma-digital.app.n8n.cloud
  • Versión de n8n: 2.20.7 (Cloud)
  • Nodo: @n8n/n8n-nodes-langchain.agent v1.8
  • Modelo: gpt-4.1-mini

Prueba reproducible — workflow minimal de 8 nodos

Manual Trigger
  → Code "Prepare Test Data"
      (obtener cada URL vía helpers.httpRequest({encoding:'arraybuffer'})
       + helpers.prepareBinaryData, emite 1 elemento por archivo con binarios)
  → Switch by MIME (PDF / Imagen / Fallback)
  → Extract from PDF (solo rama PDF)  → Merge (agregar, 3 entradas)
  → Code "Aggregate"
      (recopilar elementos en una sola salida: json.text + binary.data_0,
       data_1, ... para AI Agent)
  → AI Agent (passthroughBinaryImages: true)
  → OpenAI Chat Model

Sin memoria Postgres, sin herramientas, sin subworkflows guardados. Tan minimal como es posible mientras se reproduce el problema.

Estoy feliz de compartir el workflow JSON completo.

Resultados de pruebas

Entrada Total binario Resultado
2 iconos pequeños (webp) ~40 KB :white_check_mark: Siempre funciona
2 PDF pequeños (176 + 63 KB) ~240 KB :white_check_mark: Siempre funciona
1 PDF (2.6 MB, 5 páginas) ~2.6 MB :cross_mark: Falla
2 imágenes (1.56 MB + 810 KB webp) ~2.4 MB :cross_mark: Falla

El umbral está en algún lugar entre ~240 KB y ~2.4 MB de binarios totales en una sola ejecución. El fallo ocurre incluso con un único binario de 2.6 MB (solo una llamada helpers.httpRequest), por lo que esto no es una fuga de acumulación multi-fetch.

La parte interesante — punto de fallo no determinista

Exacta misma entrada, mismo workflow, mismo camino de ejecución:

  • Ejecución 1: falla en el nodo Code Prepare Test Data (durante helpers.httpRequest / prepareBinaryData)
  • Ejecución 2: falla en el nodo AI Agent (durante procesamiento base64 passthroughBinaryImages)
  • Ejecución 3: falla en el nodo Code de nuevo
  • (etc.)

Ambos modos de fallo producen el mismo error en la UI:

Execution stopped at this node
n8n may have run out of memory while running this execution.

“Other info” expandido solo muestra la versión de n8n + marca de tiempo. Sin stack trace visible.

Si esto fuera un error en el código del usuario, el fallo sería determinista en el mismo nodo cada ejecución. El hecho de que el punto de fallo fluctúe con la misma entrada sugiere fuertemente presión de recursos de trabajador compartido.

Prueba de control — self-hosted funciona bien

Importé el mismo workflow JSON en n8n self-hosted (Docker, n8n 2.20.7, 8 GB en el host), con los mismos servicios externos (Supabase, OpenAI).

Resultado: 30+ ejecuciones en todos los escenarios de fallo anteriores — sin ningún fallo. Incluyendo un PDF de 4.7 MB + 2 imágenes grandes simultáneamente.

Esto aísla la causa a la infraestructura de Cloud, no al workflow o mi código.

Preguntas

  1. ¿Alguien más ha experimentado esto en Cloud Starter? Específicamente OOM intermitente con cargas de sub-MB a bajo-MB en workflows que usan binary fetch + AI Agent passthroughBinaryImages?

  2. ¿Hay un presupuesto de memoria por ejecución no documentado en Starter que sea más bajo que los 1 GB de memoria de trabajador anunciados? El fallo observado a ~2 MB binarios es tres órdenes de magnitud por debajo.

  3. ¿helpers.httpRequest({encoding:'arraybuffer'}) o prepareBinaryData tienen sobrecarga de memoria conocida más allá del tamaño del búfer?

  4. ¿Hay un problema conocido con LangChain Agent v1.8 passthroughBinaryImages provocando picos de memoria para entradas > 1 MB?

  5. ¿Actualizar a Pro cambiaría significativamente la situación, o la misma infraestructura compartida afectará también a Pro?

Realmente prefiero quedarme en Cloud (queremos evitar la sobrecarga de mantenimiento del self-hosting), pero ahora mismo Starter no es estable para nuestro caso de uso.

Feliz de proporcionar:

  • Workflow JSON completo
  • IDs de ejecución fallida (para que el equipo de n8n extraiga logs del lado del servidor)
  • Puntos de datos de prueba adicionales (cargas más pequeñas, bisección, etc.)

¡Gracias por cualquier información!

3

@sawsew467 tu diagnóstico es correcto — Starter tiene un límite de memoria por ejecución bastante ajustado y estás apilando imágenes binarias + codificadas en base64 (passthroughBinaryImages infla ~33%) + agregación del nodo Code, todo en memoria al mismo tiempo. auto-hospedado con 8GB simplemente tiene mucho más margen. el workaround más rápido sin mejorar planes: elimina passthroughBinaryImages y pasa URLs de imágenes al agente en su lugar — el modelo las obtiene, tu memoria de ejecución se mantiene plana. ¿típicamente cuántas imágenes por ejecución? cambia si el paso de URL funciona o necesitas una forma completamente diferente.

4

Hola @sawsew467

Los fallos están ocurriendo porque el plan Starter de n8n Cloud tiene un límite de memoria mucho menor del que esperabas—solo 320 MB de RAM, no 1 GB. Cuando procesas archivos (como PDFs o imágenes), n8n no solo usa el tamaño real del archivo; crea múltiples copias en segundo plano y los convierte a un formato basado en texto (Base64) para que la IA pueda leerlos, lo que aumenta enormemente el uso de memoria. Debido a que estás operando justo al límite de este límite, el sistema falla aleatoriamente en cualquier nodo que haga que la memoria supere el límite durante esa ejecución específica.

Ya que tu flujo de trabajo funciona perfectamente en tu servidor autoalojado con más RAM, tu código no es el problema—el “contenedor” en la nube es simplemente demasiado pequeño para esta tarea. Para solucionar esto, la solución más efectiva es actualizar a un plan Pro, que proporciona mucha más memoria (hasta 1.2 GB). Alternativamente, podrías evitar cargar los archivos directamente en el Agente de IA y en su lugar proporcionar a la IA un enlace web al archivo, lo que omite completamente el proceso de conversión que consume mucha memoria.