Nó Execute Workflow. Branch de sucesso não dispara downstream apesar de emitir dados; ou ambas as branches disparam simultaneamente com Always Output Data ativado

Oi a todos - estou tendo um problema teimoso com o comportamento de saída dupla do nó Execute Workflow quando “On Error: Continue (using error output)” está ativado. Espero que alguém tenha enfrentado isso e encontrado um padrão limpo.

Configuração

  • Um fluxo de trabalho pai chama um subfluxo de trabalho via Execute Workflow.

  • Configurações do nó Execute Workflow:

    • Mode: Run once for each item

    • Wait for Sub-Workflow Completion: ON

    • On Error: Continue (using error output)

  • O nó terminal do subfluxo de trabalho é uma atualização do Google Sheets.

  • O pai tem duas ramificações a jusante: caminho de sucesso (cleanup + alerta Telegram + página de conclusão do formulário) e caminho de erro (alerta de erro Telegram + página de conclusão de erro).

O comportamento que estou vendo

Tenho dois modos de falha dependendo da configuração Always Output Data no nó Execute Workflow do pai:

Caso A - Always Output Data OFF no nó Execute Workflow do pai:

  • No sucesso do subfluxo de trabalho: nó terminal (atualização do Sheets) emite 1 item com dados da linha completa. A aba Success Branch do nó Execute Workflow do pai claramente mostra o item presente. Mas os nós a jusante conectados à porta de sucesso não disparam. A execução simplesmente para no Execute Workflow sem erro e sem roteamento adicional.

  • No erro do subfluxo de trabalho: a ramificação de erro dispara corretamente com o payload de erro. Limpo.

Caso B - Always Output Data ON no nó Execute Workflow do pai:

  • No sucesso do subfluxo de trabalho: tanto a ramificação de sucesso quanto a de erro disparam (sucesso com os dados reais, mas também uma execução fantasma de alguma forma).

  • No erro do subfluxo de trabalho: ambas as ramificações disparam simultaneamente: ramificação de sucesso dispara com um item placeholder vazio {}, ramificação de erro dispara com o payload de erro real. Ambos os caminhos a jusante executam em paralelo, o que causa alertas Telegram duplicados e páginas de conclusão de formulário conflitantes.

O que tentei

  1. Alternar Always Output Data no nó terminal Sheets do subfluxo de trabalho para ON, com o Always Output Data do Execute Workflow do pai OFF. O nó terminal do subfluxo de trabalho confirma que emite 1 item com dados completos quando verificado no log de sub-execução. A aba Success Branch do Execute Workflow do pai também mostra esse item. Os nós a jusante ainda não disparam.

  2. Verificado que Wait for Sub-Workflow Completion está ON.

  3. Verificada a fiação na tela - porta de sucesso para nó de cleanup, porta de erro para nó de alerta. Sem trocas acidentais.

  4. Tentei os modos “Run once for each item” e “Run once with all items”. Mesmo resultado.

  5. Redesenhei as linhas de conector da porta de sucesso. Sem mudança.

O que quero

O padrão de saída dupla padrão que a maioria das pessoas parece usar:

  • Subfluxo de trabalho tem sucesso → apenas a ramificação de sucesso dispara a jusante → cleanup + alerta de sucesso são executados.

  • Subfluxo de trabalho lança erro → apenas a ramificação de erro dispara a jusante → alerta de erro + UI de recuperação são executados.

  • Nunca ambos ao mesmo tempo.

Perguntas

  1. Continue (using error output) é conhecido por se comportar mal quando o nó terminal do subfluxo de trabalho retorna itens mas a porta Execute Workflow do pai não propaga para os nós a jusante? Existe uma versão específica do n8n Cloud onde isso é corrigido?

  2. Existe um padrão canônico que as pessoas usam para obter roteamento duplo limpo - talvez com um nó Merge, uma verificação IF em $json.error, ou alguma solução estrutural que estou perdendo?

Qualquer dica é bem-vinda. Fico feliz em compartilhar mais detalhes do que mais seria necessário (como código JSON, capturas de tela do fluxo de trabalho e outras).

Obrigado.

1 curtida

Bem-vindo @Nick_Vieru à nossa comunidade! Sou Jay e sou um criador verificado do n8n.

O comportamento de dupla ramificação com “Always Output Data” (Sempre Sair com Dados) ATIVADO é uma peculiaridade conhecida - mantenha isso DESATIVADO. O padrão mais limpo: deixe “On Error: Continue (using error output)” (Em Caso de Erro: Continuar usando saída de erro) como está, e adicione um nó IF imediatamente após o nó Execute Workflow verificando {{ $json.error !== undefined }}. As saídas de sucesso do sub-workflow não carregarão um objeto de erro; as saídas de erro carregarão. Isso oferece uma ramificação explícita e limpa sem o problema de execução fantasma.

Uma coisa que vale a pena revisar: certifique-se de que o nó terminal do seu sub-workflow não está acidentalmente suprimindo o erro antes dele chegar ao pai - se o sub-workflow tiver seu próprio manipulador de erro que captura e transforma o erro em uma saída normal, o nó Execute Workflow pai não o verá como um erro.

@Nick_Vieru
compartilhe seu json por favor.

Oi Jay, muito obrigado pela resposta rápida!

Vou tentar o que você sugeriu e te aviso se resolveu o problema!

1 curtida

[quote=“nguyenthieutoan, post:2, topic:297211”]
Bem-vindo @Nick_Vieru à nossa comunidade! Sou Jay e sou um criador verificado do n8n.

O comportamento de dupla ramificação com „Always Output Data

1 curtida

Fico feliz que deu certo! Mover o condicional IF para dentro do sub-workflow é na verdade um padrão mais limpo mesmo — mantém a lógica de bifurcação auto-contida para que o elemento pai não precise saber sobre a estrutura interna do que está chamando.

2 curtidas

Já foi corrigido, obrigado!

Fico feliz em ajudar! Se tudo está funcionando conforme esperado agora, sinta-se à vontade para marcar a resposta relevante como a solução e tenha um excelente dia!

1 curtida

Oi, sou novo no fórum. Como faço isso?

1 curtida

Ah, minha culpa – eu acabei de perceber que este tópico está na categoria “Ajude-me a Construir meu Fluxo de Trabalho”, não em “Perguntas”.
O recurso “Marcar como solução” só está disponível na categoria “Perguntas”, por isso você não está vendo a opção aqui.
Muito obrigado por estar disposto a marcar uma solução mesmo assim, eu realmente aprecio! Infelizmente esta categoria simplesmente não suporta esse recurso.