100 nodos con problemas después de clonar flujo de trabajo

Hola a todos,

Quiero tener un entorno donde tenga A<>B. Cuando A está en vivo puedo trabajar en B y así sucesivamente.
Cuando clono el flujo de trabajo para tener una copia de la versión más reciente, de repente tengo que actualizar casi todos mis nodos. Casi 100. Por ejemplo, los nodos de registro de Supabase. Pero no hay nada mal, solo tengo que abrirlo, luego obtiene la tabla de la base de datos y luego puedo cerrarlo. Pero es un proceso lento y tengo que hacerlo muchas veces. Si no lo hago, ni siquiera puedo publicar el flujo de trabajo. Parece un error en el sistema de n8n. Tal vez mi aplicación se hizo demasiado grande para n8n. ¿Pero alguien conoce una solución para esto?

¿Has intentado importar/exportar en lugar de clonar/duplicar?

También puedes copiar todos los nodos del flujo de trabajo problemático y pegarlos en un nuevo flujo de trabajo.

¿Te ayuda eso?

¡Gracias por tu respuesta rápida!

#1 Desafortunadamente, la solución de Git parece estar disponible solo en el plan Business, lo que requeriría una “actualización” mensual con costos significativamente más altos. Honestamente, eso me parece muy extraño.

#2 ¿Hay disponible un CLI de n8n?

#3 Mi experiencia con flujos de trabajo más pequeños y divididos (sub)flujos es que las cosas se vuelven menos organizadas y mucho más difíciles de rastrear. Constantemente tengo que buscar:

  • ¿qué flujo de trabajo se detuvo?

  • ¿qué flujos de trabajo están conectados?

  • ¿cuáles necesito abrir?

Especialmente con pruebas A/B. Si paso de 1 flujo de trabajo a 3 o 4 flujos de trabajo con variantes A/B, fácilmente podría terminar con 8 flujos de trabajo y versiones diferentes.

En este momento, principalmente veo desventajas, para ser honesto. Dicho esto, ¡realmente aprecio tu consejo!

@Bart_Sch
Parece que deberías volver a ingresar (credenciales),
El nodo Code no necesita credenciales, así que no se ve afectado…

Ni siquiera son credenciales. Básicamente se trata de abrir el nodo y cerrarlo. Entonces se arregla. Pero debería hacerse automáticamente, sin intervención, en mi opinión.

Perdona, pensé que lo había mencionado, pero es una instancia en la nube. No puedo usarla, lamentablemente.

¿Crees que funcionará entonces? ¿Y por qué?

¿Qué demonios? Además tengo nodos con credenciales diferentes. Así que clonar cambia el flujo de trabajo. Qué herramienta tan amateur es esta :sweat_smile:

Ay, y cuando exporto e importo, ¡el nombre cambió al exactamente el mismo nombre de flujo de trabajo! :sweat_smile: Casi rompo el que estaba funcionando…

Disculpa por todos los mensajes. Pero la descarga e importación no funcionan para mí, además hay otros conflictos porque clona exactamente todo.

Hola @Bart_Sch, gracias por la aclaración.

Creo que el problema subyacente podría estar relacionado con las credenciales, pero no en el sentido de un valor de credencial incorrecto. Dado que abrir y cerrar el nodo hace que funcione de nuevo, parece más que el nodo clonado no está resolviendo o actualizando correctamente el estado de las credenciales hasta que la UI lo recarga.

Así que el nodo Code en sí podría estar bien, mientras que el enlace de credenciales después de la clonación parece ser la parte que se está quedando atascada.

Gracias de nuevo por los detalles, eso ayuda a reducir el problema considerablemente.

Me encontré con el mismo problema antes, y lo único que me salvó la cordura fue reseleccionar la credencial en un nodo, luego duplicar ese nodo arreglado y copiar su JSON sobre los rotos. Todavía se siente un poco chapucero, pero redujo bastante el trabajo tedioso. Me hace pensar que la función de clonar simplemente olvida sincronizar los estados de credenciales en segundo plano.

@Bart_Sch

Otra solución más segura sería reconstruir el flujo de trabajo clonado en bloques en lugar de intentar reparar todos los nodos rotos de una vez. Crearía un nuevo flujo de trabajo vacío, luego copiaría un pequeño grupo de nodos del flujo de trabajo original, por ejemplo una sección o una integración a la vez. Después de pegar cada bloque, volvería a seleccionar la credencial solo una vez para ese bloque, lo probaría y luego continuaría con el siguiente bloque. Esto es más lento que un clon completo, pero más seguro que editar 100 nodos manualmente o cambiar el JSON exportado en masa, especialmente en Cloud. También ayuda a identificar qué tipo de nodo o integración está perdiendo su estado de credencial después de la clonación.
Mantenería el flujo de trabajo original sin cambios, construiría el reemplazo con un nombre temporal, probaría cada sección y solo cambiaría el tráfico de producción después de que la versión reconstruida esté completamente validada.

Gracias a todos por la ayuda. Realmente lo aprecio.

Después de algunas pruebas, finalmente me decido por la opción Descargar>Importar:

Tengo que tener cuidado porque el nombre cambia al flujo de trabajo original del que procede. Y mi flujo tiene un webhook que necesita ser cambiado y actualizado en 1 nodo después de la importación, pero es mucho mejor que reabrir todos los nodos como hice al principio.

Sigue pareciendo un poco un parche y es extraño que no haya un método real compatible para Test/Prod. Pensé que este producto era para Enterprise. Lamentablemente, la opción Git es para un plan más caro.

La segunda opción sería quizás construir algún pipeline y clonar y actualizar vía API o MCP, pero por ahora no tengo mucho tiempo para averiguarlo. Esperaba un método incorporado.

Agradezco nuevamente a todos.

Bart