Meu pipeline é composto por vários gatilhos de webhook e vários gatilhos agendados, além de cerca de 15 sub-workflows aninhados (chamados através de Execute Workflow).
Recentemente, quis configurar um ambiente de desenvolvimento. Não consigo apontar meus webhooks para um alvo de dev separado, então a melhor ideia que tive foi copiar todo o pipeline e conectar a cópia ao principal por meio de um nó IF e uma variável global dev: on/off. Quando dev está ativado, cada payload que chega é duplicado e também enviado para a cópia de dev por webhook. Quando dev está desativado, apenas prod é executado. O objetivo era testar exatamente os mesmos dados reais que chegam em prod, mas na cópia de dev, e uma vez que algo funciona lá, mover para prod. Isso importa porque, como disse, tenho cerca de 15 sub-workflows aninhados, então realmente quero validar mudanças no tráfego real antes de promovê-las.
Depois que conectei a cópia de dev ao prod, comecei a ter problemas estranhos que nunca tinha tido antes:
Alguns sub-workflows que claramente estavam publicados no workflow principal começaram a lançar erros como “sub-workflow não publicado”. Isso não fazia sentido para mim, eles estavam publicados.
Comecei a ter problemas de condição de corrida basicamente em todos os nós que tocam nas Tabelas de Dados do n8n / banco de dados incorporado.
Deletar o pipeline de dev fez com que tudo isso desaparecesse imediatamente.
Então tenho duas perguntas:
Se o n8n começou a se comportar assim (erros falsos de “sub-workflow não publicado” e condições de corrida) apenas por aproximadamente dobrar o número de sub-workflows e execuções, devo me preocupar que simplesmente crescer meu prod normal com mais sub-workflows aninhados ao longo do tempo acionará os mesmos bugs? Existe um limite conhecido ou um problema conhecido em relação ao número de sub-workflows aninhados ou execuções simultâneas no plano Pro?
Qual é a forma recomendada de construir um ambiente de desenvolvimento na minha situação? Não consigo facilmente redirecionar os webhooks, tenho muitos sub-workflows aninhados e quero testar contra os mesmos dados reais que prod recebe.
Qual é a mensagem de erro (se houver)?
“sub-workflow não publicado” em sub-workflows que estão realmente publicados, além de erros intermitentes de condição de corrida em nós que usam as Tabelas de Dados do n8n.
Compartilhe a saída retornada pelo último nó
(a chamada de sub-workflow com falha retorna o erro "sub-workflow não publicado" em vez de executar)
Informações sobre sua configuração de n8n
Versão do n8n: 2.25.7
Banco de dados (padrão: SQLite): n8n padrão
Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main): padrão (gerenciado por n8n Cloud)
Considerando que você tem 15+ fluxos de trabalho aninhados e está enfrentando condições de corrida, você superou a abordagem “single-instance” para desenvolvimento.
O padrão ouro para n8n é ter uma instância n8n completamente separada para Dev. Como você não pode alterar a fonte do webhook, use sua instância de Prod como um “proxy burro”.
Instância de Prod: Recebe o webhook → Imediatamente envia uma requisição HTTP para a URL do webhook da instância Dev → Continua com a lógica de Prod.
Instância de Dev: Uma conta/instância n8n Cloud totalmente separada.
Por que funciona: A instância Dev tem seu próprio banco de dados. Não há zero contenção de recursos. Se a instância Dev travar ou travar, tem zero impacto na sua execução de Prod.
Eu tinha o pipeline de dev exatamente como você mencionou: a cada acionamento eu tinha um nó if/else que verificava uma variável global (dev: on/off) e depois um nó HTTP POST que enviava (passava) os dados para o dev. Entendendo que essa lógica não deveria potencialmente sobrecarregar recursos, ainda assim enfrentei alguns comportamentos inesperados por parte do n8n. Talvez o n8n tenha limites de recursos quando hospedado na nuvem?
Não há um limite máximo documentado para sub-workflows. O problema que você encontrou não é sobre a quantidade, mas sobre SQLite e concorrência. Sua instância Cloud usa SQLite por padrão, e SQLite tem um bloqueio de escritor único. Quando você duplicou seu pipeline, tanto as cópias de prod quanto de dev estavam escrevendo nas mesmas Data Tables simultaneamente, causando contenção de escrita. Os erros de “sub-workflow não publicado” provavelmente são um efeito colateral dessa contenção: quando o n8n não consegue resolver uma referência de sub-workflow rápido o suficiente sob pressão de recursos, pode lançar erros enganosos. Então crescer seu prod normal ao longo do tempo não causará o mesmo problema a menos que você também esteja duplicando escritas simultâneas em Data Tables.
Para um ambiente de dev no Cloud, a abordagem de instância separada do kjooleng funciona. Uma alternativa mais barata que fica dentro de uma instância: em vez de duplicar o pipeline inteiro, use o versionamento de workflow do n8n. Faça alterações em um workflow, salve sem publicar, depois teste manualmente. As execuções de produção sempre usam a versão publicada atual, então seu prod continua executando a última versão publicada enquanto você testa alterações no rascunho salvo. Depois de validado, publique. Isso não cobre testes com tráfego de webhook ao vivo, mas evita o problema de duplicação completamente.
Para testes de tráfego ao vivo especificamente, a abordagem de proxy-para-instância-separada do kjooleng é a opção certa.
@pohgen boas notícias: sem limite rígido em sub-workflows aninhados, o crescimento da prod não vai acionar isso. Na Cloud, a concorrência (Pro = 50) conta apenas execuções de webhook/trigger, não chamadas de Execute Workflow, então mais sub-workflows aninhados não consomem seu orçamento.
O que quebrou foi clonar o pipeline na mesma instância: os erros de “sub-workflow não publicado” são cópias de prod e dev colidindo (sub-workflows duplicados deixam Execute Workflow acertar a cópia errada/não publicada), as corridas de Data Table são ambas as cópias martelando as mesmas tabelas built-in ao mesmo tempo, e você dobrou as execuções de webhook que contam para o cap de 50. A exclusão da cópia de dev consertando tudo confirma que é a duplicação, não a contagem.
Para dev: use uma instância n8n separada com suas próprias Data Tables para que não possa contender com prod. Para testar dados reais sem reapontar webhooks, capture os payloads da prod e reproduza-os em dev em vez de fazer fork de tráfego ao vivo.