Estou executando o n8n no Queue Mode (Redis + Worker + Database) e encontrei um problema onde não consigo determinar de forma confiável o último nó executado quando o Redis fica indisponível.
Descrever o problema/erro/pergunta
Durante a execução do workflow, se o Redis desconectar ou reiniciar, ocorre o seguinte comportamento:
A execução permanece em estado de execução no banco de dados
Nenhum progresso de execução é visível na UI
Após o Redis se recuperar, a execução não retoma ou atualiza o progresso
Após reiniciar a instância principal do n8n, o status de execução é atualizado para crashed
Porém, a UI e os dados de execução não mostram claramente em qual nó o workflow parou
Informações sobre sua configuração do n8n
- Versão do n8n: 2.11.4
- Banco de dados (padrão: SQLite): pgsql
- Configuração do n8n EXECUTIONS_PROCESS (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, desktop app): Docker
- Sistema operacional:
Pergunta
- Existe alguma forma oficial ou recomendada de determinar o último nó completado com sucesso neste cenário?
Oi @halouprogramer
Seu setup n8n usa Redis como um “mensageiro” para coordenar o trabalho entre o sistema principal e os workers. Quando o Redis se desconecta, o mensageiro desaparece, o que significa que o sistema principal nunca recebe o sinal de que uma tarefa foi concluída. Isso deixa a tarefa presa em um estado “executando”. Quando você reinicia o sistema, o n8n percebe que a tarefa nunca terminou oficialmente e a marca como “falha” como uma forma de limpeza.
Embora a tarefa seja rotulada como “falha”, o n8n geralmente salva os resultados de cada etapa individual (nó) no seu banco de dados conforme avança. O problema é que a interface do usuário do n8n não foi projetada para mostrar esse progresso parcial para execuções com falha. É por isso que a UI fica em branco ou não destaca onde o fluxo de trabalho parou, mesmo que os dados realmente existam.
Para descobrir exatamente qual nó foi o último a terminar, você precisa contornar a interface do usuário e procurar diretamente no seu banco de dados PostgreSQL. Ao buscar o ID de execução específico nas tabelas do banco de dados, você pode ver os dados brutos para essa execução. O último nó que salvou com sucesso sua saída no banco de dados é aquele onde o fluxo de trabalho parou.
SELECT data
FROM execution_entity
WHERE id = YOUR_EXECUTION_ID;
Nota: Execute a seguinte consulta na sua instância Postgres (substitua YOUR_EXECUTION_ID pelo ID real)
Para evitar que isso aconteça no futuro, você pode ajustar algumas configurações para tornar seu sistema mais resiliente. Aumentar o tempo limite do Redis dá ao n8n mais tempo para se recuperar de pequenas falhas de rede, e definir um “Execution Timeout” máximo garante que as tarefas presas sejam fechadas automaticamente em vez de ficar penduradas em um estado “executando” indefinidamente.
Bem-vindo à comunidade @halouprogramer!
No modo de fila, infelizmente o que você está vendo é esperado: uma vez que o Redis cai durante a execução, a instância principal nunca recebe um sinal limpo “estou pronto” do worker, então a execução fica em “em execução” até que algo a limpe, e quando é limpa, ela é marcada como “travada” sem contexto no nível do nó na interface.
Se você realmente precisar saber “onde isso parou?”, basicamente tem duas opções:
-
Para o futuro: ative “Salvar Progresso da Execução” para este fluxo de trabalho, para que o n8n escreva dados após cada nó e você possa ver o último nó concluído mesmo quando o status final é travado.
-
Agora / retroativo: consulte sua execution_entity do Postgres para a ID de execução específica e inspecione a carga útil data diretamente – aquele JSON bruto geralmente contém o último nó que conseguiu persistir sua saída, embora a interface não a exiba para execuções travadas.
Além disso, o único reparo real é manter o Redis estável (timeouts, reconexão, infra), porque enquanto o “mensageiro” puder desaparecer aleatoriamente, o n8n não tem uma maneira confiável de fechar o loop e marcar a execução com um estado final preciso.
Eu trataria isso como um problema de observabilidade e design de recuperação, não apenas um problema de Redis. Para fluxos de trabalho em produção, adicione logging de checkpoint em torno de nós críticos para que você possa dizer o que foi concluído mesmo se a interface de execução disser apenas que travou. Depois revise o comportamento de reinicialização de fila/worker e persistência do Redis, porque sem checkpoints o fluxo de trabalho pode falhar da pior maneira possível: meio caminho com nenhum ponto de retomada óbvio.