n8n terminou como Succeeded, mas nenhuma task nasceu no Semaphore: sucesso do orquestrador não é sucesso downstream

Um workflow do n8n aparecia como:

1

Succeeded

Mas a operação esperada no Semaphore não existia.

Nenhuma task tinha sido criada.

Esse é um tipo de falha perigoso porque a interface entrega uma sensação de sucesso enquanto o efeito principal do fluxo nunca aconteceu.

O problema não era “o Semaphore executou e falhou”.

Era anterior:

o workflow conseguia terminar sem chegar ao POST que criava a task.

Status do workflow mede o workflow #

Quando n8n marca uma execução como sucesso, isso significa que os nodes percorridos terminaram sem um erro não tratado.

Não significa automaticamente que:

• um e-mail foi recebido;
• uma task foi criada;
• um deploy aconteceu;
• uma mensagem foi entregue;
• um recurso cloud foi alterado.

Cada efeito downstream precisa de um critério próprio.

Primeiro: definir qual evento prova sucesso de negócio #

Nesse fluxo, o objetivo era criar uma task no Semaphore.

Então o evento mínimo de sucesso não deveria ser:

1

workflow chegou ao fim

E sim algo como:

1
2
3

Semaphore aceitou o POST
+
retornou identificador/status compatível com task criada

Idealmente, para operações longas:

1
2
3
4

task criada
→ polling
→ task finalizada
→ resultado validado

Seguir o caminho node por node #

A investigação recuperada mostrou alguns pontos em que a execução podia sair antes do Semaphore:

• normalização descartando campos importantes;
• branch de confirmação;
• classificação via IA;
• validação de template;
• validação de host;
• body incorreto no node HTTP.

Então o debug correto não era olhar apenas o último node verde.

Era perguntar:

1
2
3
4
5
6

o template_id chegou até o node HTTP?
o limit chegou?
o branch passou pela IA ou fez bypass?
o body enviado tinha o contrato certo?
o node Enviar para Semaphore executou?
qual resposta HTTP ele recebeu?

Um bug real: campos foram descartados na normalização #

No clone de homologação analisado, a normalização inicial preservava alguns campos, mas descartava valores operacionais que já tinham sido fornecidos na entrada.

Entre os campos adicionados depois à normalização estavam:

1
2
3
4
5

template_id
limit
server_name
server_action
deploy_service

Se template_id e limit desaparecem no começo, o restante do workflow pode tomar decisões como se o usuário nunca tivesse fornecido esses dados.

Nenhum erro de JavaScript é obrigatório para isso acontecer.

É uma falha de contrato de dados.

Outro bug: o body do POST não seguia o contrato validado #

O contrato da API do Semaphore foi testado separadamente por curl.

A estrutura sanitizada era equivalente a:

1
2
3
4
5
6
7

{
  "template_id": 123,
  "params": {
    "limit": ["host-exemplo"]
  },
  "message": "operação controlada"
}

A validação externa foi importante porque separou duas perguntas:

1

A API do Semaphore aceita esse payload?

de:

1

O n8n está realmente enviando esse payload?

Quando curl funciona e o workflow não cria task, a investigação migra para a construção/roteamento do workflow.

Não use mensagem fixa para um fluxo genérico #

Outro ajuste foi tornar a mensagem enviada ao Semaphore dinâmica conforme template e target.

Uma string hardcoded para uma operação específica pode:

• confundir auditoria;
• esconder qual receita foi acionada;
• indicar que o node foi copiado de outro fluxo sem revisar contrato.

Uma mensagem operacional deve carregar contexto suficiente para rastrear a task.

Node não executado é diferente de node executado com 2xx #

No histórico do n8n, eu separo:

Caso A — node HTTP não foi percorrido #

Problema de branch/condição/dados.

Caso B — node HTTP executou e retornou erro #

Problema de contrato, autenticação, validação ou serviço downstream.

Caso C — node HTTP retornou sucesso, mas não há task #

Confirmar semântica da resposta e endpoint; talvez 2xx não signifique criação efetiva ou a resposta tenha sido interpretada errado.

Caso D — task existe, mas falhou depois #

Agora a investigação pertence ao Semaphore/Ansible.

Misturar esses estados cria troubleshooting impreciso.

Instrumentar o fluxo com IDs e checkpoints #

Eu gosto de preservar um externalKey/correlation ID desde a entrada.

Depois registrar em pontos importantes:

1
2
3
4
5
6

entrada normalizada
classificação/decisão
confirmação
POST downstream
ID da task downstream
resultado final

Isso permite correlacionar:

1
2
3
4

requisição do usuário
↔ execução n8n
↔ task Semaphore
↔ PLAY RECAP

Sem depender só de timestamp aproximado.

O node HTTP precisa validar resposta #

Não basta configurar “Continue On Fail” e deixar qualquer resposta seguir.

O fluxo deveria verificar explicitamente:

1
2
3
4

status HTTP esperado
body esperado
ID/status da task
mensagem de erro do Semaphore

Se a criação falhou, a execução de negócio deve ficar em estado de erro mesmo que o n8n consiga responder ao webhook de forma controlada.

“Responder ao usuário” e “executar operação” são estados independentes #

Um webhook pode responder 200 com algo como:

1
2
3
4

{
  "ok": false,
  "status": "aguardando_confirmacao"
}

Isso é perfeitamente válido.

O erro é a observabilidade interna tratar todo HTTP 200 do próprio workflow como se a automação tivesse acontecido.

Eu separaria estados:

1
2
3
4
5
6
7
8

recebido
validado
aguardando confirmação
rejeitado
submetido ao Semaphore
task em execução
concluído
falhou

Teste fora do n8n reduz a área de suspeita #

Uma técnica que funcionou nesse caso foi validar o endpoint do Semaphore diretamente.

Com o contrato conhecido, o workflow pôde ser comparado com uma chamada mínima reproduzível.

Esse padrão vale para qualquer integração:

1

n8n → API externa

Antes de desmontar o workflow inteiro, prove a API com um cliente simples.

O que a fonte sustenta #

O changelog e os registros da investigação documentam que:

• o clone de homologação podia terminar Succeeded sem chegar ao Semaphore;
• template_id e limit eram descartados na normalização anterior;
• o body do node de envio estava incorreto;
• o contrato correto foi validado por chamada direta à API;
• a normalização passou a preservar campos operacionais;
• o body passou a ser dinâmico;
• host inválido passou a retornar erro sem ampliar escopo.

IDs reais de workflow, template e hostname foram omitidos.

Checklist para “verde sem efeito” #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[ ] qual evento downstream define sucesso real?
[ ] o node que produz esse efeito foi executado?
[ ] todos os campos chegaram até ele?
[ ] branch/IF desviou o fluxo antes?
[ ] payload foi capturado e comparado com contrato?
[ ] API funciona fora do n8n?
[ ] status HTTP é validado?
[ ] response body é validado?
[ ] ID downstream é armazenado?
[ ] existe correlation ID ponta a ponta?
[ ] workflow distingue recebido/submetido/concluído?

O principal aprendizado #

Orquestrador verde prova apenas que o caminho executado não terminou em erro não tratado.

Para automação operacional eu preciso de algo mais forte:

provar o efeito downstream que justificou executar o workflow.

Se nenhuma task nasceu no Semaphore, o job de negócio não teve sucesso — mesmo que o n8n esteja todo verde.