Estoy en n8n Cloud Starter, versión 2.17.5.
Un flujo de trabajo que procesa ~120–400 elementos mediante Loop Over Items y HTTP Requests obtiene “conexión perdida / sin conexión” y la ejecución se interrumpe.
Los datos de ejecución no son confiables o no se guardan correctamente.
Esto sucede incluso después de reducir la carga útil y usar Data Tables.
¿Pueden confirmar si se trata de un problema de recursos/tiempo de espera en la nube y si mi plan puede soportar esta carga de trabajo?
¡Hola @kourG, bienvenido!
Yo diría que este número puede ser una limitación de tu plan de iniciación en la nube si tu flujo de trabajo no está optimizado, aunque 120-400 sigue siendo bastante para el acceso de cómputo del plan de iniciación:
Aquí hay algunas orientaciones que puedes considerar para optimizar ese flujo:
Actualizar tu plan también puede resolver eso, pero depende de tu caso de uso; si crece, es posible que necesites pasar a uno aún mayor.
En Cloud Starter, 120 a 400 elementos a través de Loop Over Items más HTTP Requests que dan error de “connection lost” generalmente significa que la ejecución está excediendo el límite de memoria o tiempo del plan, no tu internet, especialmente si cada elemento tiene una carga útil considerable, porque n8n mantiene los datos de ejecución en memoria durante la ejecución.
Algunas cosas que ayudan. Reduce lo que cada elemento lleva antes del bucle, elimina campos que no necesitas para que la carga útil en memoria se mantenga pequeña, el bucle la mantiene toda. Procesa en sub-lotes más pequeños y escribe los resultados conforme avanzes (en una Data Table o almacenamiento externo) en lugar de acumular todo en una única ejecución, así si falla a mitad del camino no pierdes toda la ejecución. Y considera dividir el trabajo: un flujo de trabajo que pone en cola los elementos, un segundo activado por cada lote, para que ninguna ejecución tenga que mantener 400 elementos de estado.
La parte de “datos de ejecución no confiables o no guardados” es el riesgo real para ti, porque una ejecución que se interrumpe a mitad de un bucle a menudo ya ha realizado la mitad de las escrituras HTTP, y no puedes saber cuál de la ejecución rota. Haz que las escrituras sean idempotentes y realiza un seguimiento de qué elementos se completaron en una tabla externa, así una re-ejecución omite los que ya están hechos en lugar de duplicarlos. ¿Falla en un número de elementos consistente, o aleatoriamente? Un número consistente apunta al techo de memoria.
Ya he intentado reducir el tamaño de la carga y almacenar datos intermedios en tablas de datos. Sin embargo, cuando ocurre el problema de “conexión perdida / sin conexión”, parece que no queda ningún dato en la tabla, como si la ejecución nunca se hubiera completado o los resultados intermedios nunca se hubieran guardado.
Por esto, estoy intentando entender si el problema está relacionado con un límite de recursos de Cloud Starter o un tiempo de espera de ejecución.
Respecto a la sugerencia de usar lotes, si entiendo correctamente, me estás recomendando que divida los 120–400 elementos en grupos más pequeños y los procese de forma incremental en lugar de en una sola ejecución grande. También estoy considerando si sería posible cargar un nuevo lote después de que el lote actual haya terminado de procesarse en el bucle, para que el flujo de trabajo pueda continuar en fragmentos más pequeños. Experimentaré con este enfoque y veré si mejora la estabilidad.
Además, estoy usando n8n Cloud Starter y no tengo control directo sobre la actualización de la versión de n8n, ya que la versión es gestionada por n8n Cloud. ¿Podrías confirmar si la versión 2.23.4 ya está disponible en Cloud, o si se requiere alguna acción del equipo de n8n?
Sí, pero haz que cada lote sea su propia ejecución. Un Loop Over Items que carga el siguiente lote dentro de la misma ejecución sigue compartiendo una única envoltura de timeout/memoria, por lo que cuando esa ejecución se interrumpe, el punto de control puede desaparecer con ella.
Usa una ejecución para reclamar un lote pequeño, escribe el resultado/estado de cada elemento antes de pasar al siguiente, luego deja que un Schedule o Execute Workflow inicie el siguiente lote a partir de las filas aún marcadas como pendientes. Para el síntoma de Data Table, publica dónde se encuentra el nodo de escritura: antes de la HTTP Request, después de cada elemento, ¿o solo después de que termina todo el bucle?