Por algum motivo, os nós que estão fixados no meu workflow estão aparecendo como “Fixado” na aba de execução, mesmo que a execução não seja uma execução de teste.
Parece que sua interface do n8n está exibindo um badge “Fixado” por erro, o que é provavelmente um erro visual em vez de um problema com seus dados reais de fluxo. Mesmo que você tenha desafixado o nó, seu navegador ou o serviço de nuvem n8n pode estar “lembrando” da configuração antiga devido a um erro de cache. Isso significa que seu fluxo provavelmente está funcionando normalmente com dados reais, mas a tela está exibindo incorretamente o status de fixado.
Para corrigir isso, você deve primeiro tentar uma “atualização forçada” do seu navegador (Ctrl+F5 ou Cmd+Shift+R) para limpar qualquer informação presa. Se isso não funcionar, tente deletar o nó e adicionar um novo para redefinir suas configurações. Você pode verificar se o problema é apenas um erro visual baixando seu fluxo como um arquivo JSON; se a palavra “pinData” não aparecer nesse arquivo, então seu fluxo está perfeitamente bem e o badge “Fixado” é simplesmente um erro de exibição que você deve reportar ao suporte do n8n help@n8n.io
@Evan711 o ícone laranja/amarelo em “When Executed by Another Workflow” pode não ser o indicador de dados fixados — também pode ser a deixa visual do n8n indicando que o gatilho recebeu dados de entrada do nó Execute Workflow de um fluxo de trabalho pai. o conteúdo efetivamente fixado ainda está aparecendo no painel de entrada/saída daquele nó quando vc clica nele, ou é só o ícone que está lendo como fixado?
Bem-vindo @Evan711 à nossa comunidade! Sou Jay e sou um criador verificado n8n.
O instinto de Achamm está certo - o indicador laranja no nó de disparo “When Executed by Another Workflow” não significa que pinData está ativo. É a dica visual do n8n indicando que o disparo recebeu dados ao vivo do nó Execute Workflow de um fluxo de trabalho pai. Este é o comportamento esperado para sub-fluxos de trabalho.
Para confirmar que não há pinData real deixado no nó, faça download do seu fluxo de trabalho como JSON e procure pela string pinData dentro do arquivo. Se estiver ausente, os dados naquele nó são 100% dados ao vivo do pai, não fixados - o emblema é apenas a forma da interface mostrar que o nó recebeu entrada externamente em vez de disparar seu próprio disparo. Você pode ignorá-lo com segurança.
Estou postando aqui em vez de abrir uma nova issue porque tenho certeza de que estou vendo a mesma coisa. Tive um problema esta manhã onde um webhook foi acionado três vezes. Quando olho para o nó webhook no n8n, ele não apenas mostra que os dados estão fixados, mas mostra os dados fixados na saída em vez dos dados reais que acionaram o webhook. Definitivamente não está mostrando os dados de execução reais.
Criei dois vídeos que demonstram isso em ação. O primeiro é uma demonstração do problema. O segundo é uma demonstração de por que isso é um problema, onde tenho o Baserow afirmando que acionou o webhook uma vez, mas n8n afirmando que foi acionado três vezes. Esse problema com dados fixados aparecendo na aba Executions torna impossível solucionar problemas quando os dados do webhook ainda estão fixados na aba Editor.
Abri uma issue no GitHub para isso, já que tenho certeza de que essa comunidade é apenas suporte teatral copy/paste gerado por IA de cegos guiando cegos. Só queria que o OP soubesse que ele não está louco e respostas como “faça um hard-refresh no seu navegador porque é um erro visual” ou “está tudo bem porque provavelmente não é real” podem ser descartadas como uma resposta.
Obrigado, Adrian! Seu vídeo demonstra exatamente o problema que estou enfrentando. Fico feliz em saber que não sou o único maluco. É definitivamente um problema com o n8n e não com meu navegador.
Estou enfrentando exatamente o mesmo problema e ele está causando erros críticos em nossos fluxos de trabalho.
Exatamente como você mencionou, os nós fixados agora estão vazando para execuções em produção. Isso derrota completamente o propósito do recurso, pois confiamos em dados fixados apenas para testar fluxos no editor sem afetar o fluxo de trabalho publicado ao vivo. Agora, todos os nossos webhooks/gatilhos ativos estão ignorando os dados reais recebidos e usando os dados simulados fixados.
Este é um bug crítico para qualquer pessoa que execute n8n em produção. Alguém encontrou uma solução alternativa para contornar isso enquanto aguardamos uma correção oficial do time n8n?
Eu não estou vendo dados fixados entrarem na execução de produção. Apenas que o painel de execução mostra dados fixados em vez dos dados reais do gatilho. Se você tem prova de que seus workflows de produção estão rodando com dados fixados, eu encorajaria você a fazer um vídeo disso e anexar à issue que levantei e linkei acima. Ou abra uma nova issue e coloque “crítico” ou “urgente” ou algo assim na linha de assunto para que alguém realmente dê uma olhada nela. Se isso está genuinamente acontecendo, é uma issue crítica, e eles vão corrigir imediatamente.
Meu problema foi fechado como duplicado de uma issue anterior que, segundo eles, era uma regressão (forma sofisticada de dizer, “um bug involuntário que foi introduzido por uma nova funcionalidade e quebrou algo que já estava funcionando”) e agora será corrigido na versão 2.22.6. Eles pediram desculpas pelo incômodo.
Você está absolutamente certo. Depois de fazer testes mais profundos com base na sua resposta, percebi que o problema é de fato visual, exatamente como você descreveu.
Os dados de entrada reais estão sendo processados corretamente por trás dos panos. Porém, o fator agravante principal é que o painel de execução mascara completamente isso. Ele mostra o fluxo de trabalho processando os dados fixados, o que significa que perdemos completamente a capacidade de inspecionar ou acessar os dados de produção reais nos logs de execução.
Então, embora não esteja literalmente quebrando o fluxo ao enviar dados simulados para a produção, isso se torna um pesadelo para depuração e monitoramento, já que temos acesso apenas aos resultados visuais dos dados fixados.
Fico muito feliz em saber que eles reconheceram isso como uma regressão e que uma correção já está a caminho para a versão 2.22.6. Obrigado por me apontar na direção certa e esclarecer o comportamento!
O rótulo “Pinned” (Fixado) no log de execução é um registro histórico; ele mostra o que foi executado durante aquela execução específica, não o estado atual do seu fluxo de trabalho.
Qualquer execução que foi acionada enquanto o nó estava fixado mostrará Fixado permanentemente, mesmo depois que você desfix. Essa parte é esperada e não mudará.
A questão é se novas execuções após desfix + republicação também estão mostrando Fixado. Se estiverem, tente primeiro uma atualização forçada (Ctrl+Shift+R); às vezes o navegador fornece uma versão em cache do fluxo de trabalho, e o desfix não chega ao servidor. Depois acione uma nova execução e verifique essa especificamente.
Se novas execuções ainda mostrarem Fixado após a atualização forçada, exporte o JSON do fluxo de trabalho e procure por uma chave pinData naquele nó. Se ela ainda estiver lá, o desfix não foi persistido; o salvamento falhou silenciosamente.
Delete-a do JSON, reimporte, republique, e você deve estar resolvido.
