O n8n 2.41.6 corrige uma situação em que um erro não tratado podia encerrar o processo responsável por tarefas JavaScript. O efeito não ficava restrito ao código problemático: outras tarefas que estavam em andamento no mesmo executor também falhavam.
O n8n cria automações conectando etapas em um workflow. Uma dessas etapas pode executar código. Para realizar esse trabalho, a plataforma usa um executor de tarefas, ou task runner: um processo que pode ter mais de uma tarefa em andamento.
Como um erro acabava afetando trabalhos simultâneos
Em JavaScript, uma operação assíncrona pode começar agora e terminar depois. Quando ela falha, o programa precisa tratar essa rejeição. Segundo a PR #40092, o executor não tinha um tratador para rejeições que escapavam desse cuidado, inclusive as originadas em uma etapa de código.
Nessa situação, o comportamento padrão do ambiente Node.js encerrava o processo. Todas as outras tarefas ainda em andamento naquele executor podiam apresentar falha de execução do componente, mesmo sem serem a origem do erro.
O executor registra um aviso e permanece ativo
A correção instala um tratador na inicialização do processo. Ao receber uma rejeição não tratada, ele escreve um aviso e mantém o executor funcionando. A mudança contém o encerramento do processo; não transforma um código defeituoso em código correto nem promete recuperar automaticamente a operação que falhou.
O registro também tem limites definidos. Quando o motivo é um erro, sua descrição é formatada para inspeção. Para outros valores, o aviso informa apenas o tipo, evitando registrar diretamente conteúdos que podem ser dados de itens ou de requisições. A descrição fica limitada a mil caracteres.
O aviso não inclui um identificador de tarefa, porque o tratador recebe o motivo da rejeição e várias tarefas podem estar ativas ao mesmo tempo. Por isso, não é seguro atribuí-lo a um workflow apenas pela proximidade de horário.
Como validar a continuidade do processo
Em homologação, use um fluxo isolado que reproduza a rejeição não tratada e mantenha outra tarefa controlada em andamento no mesmo executor. Confira os registros, a permanência do processo e a conclusão da tarefa independente. Depois, rode uma nova tarefa para verificar que o atendimento continua.
Esse teste deve ficar fora da produção e não substitui corrigir a origem do erro no código. O critério específico desta versão é impedir que uma rejeição sem tratamento encerre o executor e arraste os demais trabalhos, não eliminar todas as possíveis falhas de automação.