O n8n 2.43.6 corrige uma falha no recebimento de XML por webhooks. Duas requisições grandes chegando ao mesmo tempo podiam provocar erros e deixar as próximas requisições XML sem resposta até o reinício do processo. A mudança separa o processamento de cada pedido e trata outro erro que também podia deixar a leitura pendente.
Um webhook é um endereço que recebe dados enviados por outro sistema para iniciar uma automação. XML é um formato de documento usado nessas integrações. Antes de executar as etapas do workflow, o n8n precisa interpretar esse documento e convertê-lo em dados que os nós consigam utilizar.
Por que dois documentos podiam interferir um no outro
O componente responsável pela leitura utilizava uma única instância do interpretador xml2js para todas as requisições. Esse interpretador guarda informações temporárias do documento em processamento. No modo assíncrono, corpos com mais de 10 mil caracteres são lidos em partes, permitindo que outras tarefas ocorram entre elas.
Quando duas leituras grandes se sobrepunham, ambas alteravam o mesmo estado. Conforme a PR, isso podia gerar resposta 422 de falha na interpretação. Depois, o interpretador compartilhado deixava de emitir os sinais de conclusão ou erro, e os próximos pedidos XML aguardavam até o tempo limite do cliente.
O que foi alterado na leitura do XML
Cada requisição agora recebe um interpretador próprio, mantendo as opções anteriores. A versão também aplica uma correção local à biblioteca para encaminhar corretamente erros ocorridos durante a leitura assíncrona. Um elemento chamado _, por exemplo, podia provocar um erro que não chegava à rotina que aguardava a conclusão.
Nesse caso problemático, o objetivo é devolver o erro 422 em vez de manter a requisição indefinidamente pendente. Isso não significa aceitar qualquer XML: documentos que não podem ser interpretados continuam sujeitos a rejeição. A PR informa que corpos JSON, formulários e texto simples não eram afetados pelo problema de estado compartilhado.
Como validar a integração afetada
Em um ambiente de teste, envie pelo menos duas requisições XML grandes simultaneamente para um webhook de produção e, depois, envie uma pequena. Confira se todas recebem resposta e se os dados válidos chegam corretamente às etapas seguintes. O pedido pequeno posterior é importante para verificar que o interpretador não ficou inutilizável.
Valide também o tratamento de um XML problemático, esperando uma resposta de erro em vez de silêncio. Faça backup antes da atualização e compare os registros do webhook; essa correção não substitui a validação dos dados exigidos pela sua automação.