Olá a todos,
Recentemente enfrentei esse problema e corrigi manualmente. Postando minhas descobertas aqui caso não seja um comportamento intencional — ou caso o Assistente de IA precise melhorar.
O Problema
Pedi ao Assistente de IA do n8n para renomear alguns nós em um de meus fluxos de trabalho. Ele fez a edição e tudo parecia bem na tela. Mas logo após, o fluxo de trabalho ficou completamente impossível de salvar — cada edição que fiz depois disso falhou com:
Problema ao salvar fluxo de trabalho
Salvamento automático falhou: Não é possível converter indefinido ou nulo para objeto
O console do navegador mostrou o mesmo erro disparando repetidamente do renderizador de tela e do manipulador de salvamento:
Os Sintomas (IA)
- Renomear era a única coisa que pedi ao Assistente de IA para fazer, mas após sua edição, o JSON do fluxo de trabalho voltou com vários campos em nível de nó explicitamente definidos como
null— coisas comocredentials,webhookId,notes,notesInFlow,executeOnce,retryOnFail,alwaysOutputDataeonError. - Qualquer nó que normalmente não precisasse dessas propriedades simplesmente omite a chave inteiramente em uma exportação padrão do n8n. A edição do Assistente de IA em vez disso as escreveu como
null. - Uma vez que essa forma atingiu a tela, cada ação subsequente (mover um nó, salvar, salvar automaticamente) travou com o mesmo erro
Object.keys, porquenodeTransforms.tstenta normalizar esses campos e não espera umnullliteral.
A Causa Raiz (IA)
nodeTransforms.ts (usado tanto pela lógica de diff da tela quanto por useWorkflowSaving.ts) chama Object.keys(...) em certas propriedades de nó (como credentials) ao calcular o diff para salvar. Object.keys(null) lança uma exceção, então assim que um nó no fluxo de trabalho tiver null em vez de uma chave omitida, salvar/salvar automaticamente o fluxo de trabalho inteiro quebra — não apenas esse nó.
Parece que o caminho de edição de nó do Assistente de IA serializa o objeto de nó sem descartar chaves que resolvidas para null, o que produz um JSON tecnicamente válido, mas um formato de nó não seguro para o frontend.
A Solução (manualmente)
Exporte o JSON do fluxo de trabalho, remova qualquer chave em qualquer nó cujo valor seja null (em vez de configurá-lo como null), e reimporte. Por exemplo, nos nós afetados, remova chaves como:
"credentials": null,
"webhookId": null,
"notes": null,
"notesInFlow": null,
"executeOnce": null,
"retryOnFail": null,
"alwaysOutputData": null,
"onError": null
para que o objeto de nó simplesmente não tenha essas chaves se não as usar. Após remover os campos null e reimportar (Importar do Arquivo em um novo fluxo de trabalho, não colar na tela), o fluxo de trabalho foi salvo e salvo automaticamente normalmente novamente.
Espero que isso economize algumas horas de depuração de alguém!
Isso parece ser um bug em como o Assistente de IA serializa edições de nó — agradeceria uma confirmação da equipe do n8n, já que qualquer pessoa editando em lote nós com ele poderia bater na mesma parede.

