Describe the problem/error/question
Mi pipeline está compuesta por varios webhook triggers y varios schedule triggers, más alrededor de 15 sub-workflows anidados (llamados a través de Execute Workflow).
Hace poco quise configurar un entorno de desarrollo. No puedo apuntar mis webhooks a un objetivo de desarrollo separado, así que la mejor idea que se me ocurrió fue copiar todo el pipeline y conectar la copia al principal a través de un nodo IF y una variable global dev: on/off. Cuando dev está activado, cada payload entrante se duplica y también se envía a la copia de desarrollo a través de un webhook. Cuando dev está desactivado, solo se ejecuta prod. El objetivo era probar exactamente los mismos datos reales que llegan a prod, pero en la copia de desarrollo, y una vez que algo funciona allí, moverlo a prod. Esto es importante porque, como dije, tengo alrededor de 15 sub-workflows anidados, así que realmente quiero validar los cambios en tráfico real antes de promoverlos.
Después de conectar la copia de desarrollo a prod, comencé a tener problemas extraños que nunca había tenido antes:
- Algunos sub-workflows que claramente estaban publicados en el workflow principal comenzaron a lanzar errores como “sub-workflow no publicado”. Eso no tenía sentido para mí, estaban publicados.
- Comencé a tener problemas de race condition en básicamente cada nodo que toca las n8n Data Tables / BD integrada.
Eliminar el pipeline de desarrollo hizo que todo esto desapareciera inmediatamente.
Así que tengo dos preguntas:
- Si n8n comenzó a comportarse así (falsos errores de “sub-workflow no publicado” y race conditions) solo por duplicar aproximadamente el número de sub-workflows y ejecuciones, ¿debería preocuparme de que simplemente expandir mi prod normal con más sub-workflows anidados con el tiempo dispare los mismos bugs? ¿Hay un límite conocido o un problema conocido alrededor del número de sub-workflows anidados o ejecuciones concurrentes en el plan Pro?
- ¿Cuál es la forma recomendada de construir un entorno de desarrollo en mi situación? No puedo redirigir fácilmente los webhooks, tengo muchos sub-workflows anidados, y quiero probar contra los mismos datos reales que recibe prod.
What is the error message (if any)?
“sub-workflow no publicado” en sub-workflows que en realidad están publicados, más errores de race condition intermitentes en nodos que usan las n8n Data Tables.
Share the output returned by the last node
(la llamada al sub-workflow que falla devuelve el error "sub-workflow no publicado" en lugar de ejecutarse)
Information on your n8n setup
- n8n version: 2.25.7
- Database (default: SQLite): default n8n
- n8n EXECUTIONS_PROCESS setting (default: own, main): default (n8n Cloud managed)
- Running n8n via (Docker, npm, n8n cloud, desktop app): n8n Cloud
- Operating system: n8n Cloud
- Plan: Pro, around 30k executions/month
Hola @pohgen
Dado que tienes más de 15 flujos de trabajo anidados y estás experimentando condiciones de carrera, has superado el enfoque de “instancia única” para desarrollo.
El estándar de oro para n8n es tener una instancia de n8n completamente separada para Dev. Como no puedes cambiar la fuente del webhook, utiliza tu instancia de Prod como un “proxy simple”.
- Instancia de Prod: Recibe el webhook → Envía inmediatamente una HTTP Request a la URL del webhook de la instancia de Dev → Continúa con la lógica de Prod.
- Instancia de Dev: Una cuenta/instancia de n8n Cloud totalmente separada.
- Por qué funciona: La instancia de Dev tiene su propia base de datos. No hay cero contención de recursos. Si la instancia de Dev se bloquea o se congela, no tiene ningún impacto en tu ejecución de Prod.
Hola @koushikromel
Tenía el pipeline de desarrollo exactamente como mencionas: en cada activación tenía un nodo if/else que verificaba una variable global (dev: on/off) y luego un nodo HTTP POST que enviaba (pasaba) datos al dev. Entiendo que esta lógica no debería sobrecargar potencialmente los recursos, pero aun así he enfrentado un comportamiento inesperado por parte de n8n. ¿Quizás n8n tiene límites de recursos cuando está alojado en la nube?
hola @pohgen
para responder tus preguntas específicas:
- No hay un límite máximo documentado en sub-workflows. El problema que encontraste no se trata de cantidad, sino de SQLite y concurrencia. Tu instancia de Cloud usa SQLite por defecto, y SQLite tiene un bloqueo de escritor único. Cuando duplicaste tu pipeline, tanto las copias de prod como las de dev escribían en las mismas Data Tables simultáneamente, causando contención de escritura. Los errores de “sub-workflow no publicado” probablemente sean un efecto secundario de esta contención: cuando n8n no puede resolver una referencia de sub-workflow lo suficientemente rápido bajo presión de recursos, puede lanzar errores engañosos. Entonces, que tu prod normal crezca con el tiempo no causará el mismo problema a menos que también estés duplicando escrituras concurrentes en Data Tables.
- Para un entorno de dev en Cloud, el enfoque de instancia separada de kjooleng funciona. Una alternativa más económica que se mantiene dentro de una instancia: en lugar de duplicar todo el pipeline, usa el versionado de workflows de n8n. Haz cambios en un workflow, guarda sin publicar, luego prueba manualmente. Las ejecuciones de producción siempre usan la versión actualmente publicada, así que tu prod sigue ejecutando la última versión publicada mientras pruebas cambios en el borrador guardado. Una vez validado, publica. Esto no cubre pruebas con tráfico webhook en vivo, pero evita el problema de duplicación por completo.
Para pruebas de tráfico en vivo específicamente, el enfoque de proxy-a-instancia-separada de kjooleng es lo correcto.
¡Espero que esto te ayude!
@pohgen buenas noticias: sin límite fijo en sub-flujos anidados, el crecimiento de producción no lo activará. En Cloud, la concurrencia (Pro = 50) solo cuenta ejecuciones de webhook/disparador, no llamadas de Execute Workflow, así que más sub-flujos anidados no consumen tu presupuesto.
Lo que lo rompió fue clonar el pipeline en la misma instancia: los errores “sub-flujo no publicado” son copias de producción y desarrollo chocando (los sub-flujos duplicados permiten que Execute Workflow llegue a la copia equivocada/no publicada), las carreras de Data Table son ambas copias golpeando las mismas tablas integradas a la vez, y duplicaste las ejecuciones de webhook que sí cuentan hacia el límite de 50. El hecho de que eliminar la copia de desarrollo lo arreglara todo confirma que es la duplicación, no el recuento.
Para desarrollo: usa una instancia n8n separada con sus propias Data Tables para que no pueda competir con producción. Para probar datos reales sin reapuntar webhooks, captura los payloads de producción y reprodúcelos en desarrollo en lugar de bifurcar tráfico en vivo.