Nó Editar campos - problema

Ao executar o workflow, o nó Edit Fields retorna NULL para modifyTime (expressão: {{ $json.modifyTime.substring(0, 10) }} ). Ao executar o nó manualmente, a saída está correta - veja o anexo.

Por favor, compartilhe seu fluxo de trabalho para fornecer mais contexto

@Massimiliano_Bellini parece que um dos itens que entra não tem modifyTime definido, então o substring explode com undefined. execuções manuais usam dados fixados, mas execuções completas atingem todo item. proteja:

{{ ($json.modifyTime ?? '').substring(0, 10) }}

também verifique o nó que alimenta, provavelmente retornando itens onde esse campo está faltando

@Massimiliano_Bellini , você também pode adicionar uma verificação de nulo

{{ $json.modifyTime ? $json.modifyTime.substring(0, 10) : null }}

Fluxo de trabalho muito simples

Removi um item sem o “modifyTime” mas recebo o mesmo NULL quando executo o workflow - veja em anexo

Olá pessoal, atualização rápida: como solução alternativa, adicionei um nó Date & Time para formatar a data - garantindo que as outras entradas do nó também sejam incluídas na sua saída. Isso funciona bem.

Ainda tenho uma pergunta: cometi um erro no meu fluxo de trabalho anterior, ou há um bug no nó Edit Fields (Set) versão 3.4?

Ótima investigação, @Massimiliano_Bellini! Fico feliz que o workaround do nó Date & Time tenha resolvido o problema.

Para responder sua pergunta - isso é mais provável que seja uma inconsistência de dados do que um bug no próprio Edit Fields. Aqui está o que provavelmente está acontecendo:

O nó FTP list retorna arquivos do servidor FTP, e alguns desses arquivos podem genuinamente não ter nenhum valor modifyTime definido no lado do servidor (null ou ausente completamente). Quando você executa o nó manualmente via “Execute Step”, você provavelmente está olhando apenas para o primeiro item na saída de teste, que por acaso tem um modifyTime válido. Mas em uma execução de workflow completo, todos os 9 itens são processados, e alguns deles não têm esse campo - é por isso que você obtém NULL.

A expressão {{ $json.modifyTime.substring(0, 10) }} lança um TypeError quando modifyTime é null ou undefined, e o n8n silenciosamente retorna null para esse campo nesse caso.

O fix apropriado é proteger contra null, exatamente como outros sugeriram:

{{ ($json.modifyTime ?? '').substring(0, 10) }}

Ou se você quiser preservar null para arquivos sem um tempo de modificação:

{{ $json.modifyTime ? $json.modifyTime.substring(0, 10) : null }}

Sua abordagem com o nó Date & Time também funciona bem porque força o n8n a lidar com a formatação de datetime em uma etapa dedicada que consegue lidar com o caso null de forma mais elegante.

Se isso esclarece as coisas, sinta-se livre para marcar uma das respostas como Solution para que outros com o mesmo problema de FTP + campo null possam encontrar essa thread!

Olá Jay, obrigado por dedicar um tempo para analisar meu problema. Agradeço também aos outros que me enviaram suas avaliações e sugestões. Com base no que todos vocês disseram, cheguei à conclusão de que o que estou experimentando não é realmente um bug. No entanto… o nó FTP retorna um valor “modifyTime” corretamente definido para cada item/arquivo. Por favor, dê uma olhada no novo teste que acabei de executar — você pode ver que, ao executar o fluxo de trabalho, a data formatada está entre aspas "

Edit Fields node - issue (debug).pdf (258,5 KB)

@Massimiliano_Bellini Obrigado por compartilhar o PDF de depuração! Esse comportamento de quebra de cotação é bastante revelador.

Quando a data formatada aparece como "2025-01-01" (com caracteres de aspas literais), isso geralmente significa uma de duas coisas:

1. O valor do nó FTP é uma string JSON que já contém aspas escapadas. Por exemplo, o valor bruto pode ser "2025-01-01" como uma string, em vez de 2025-01-01. Você pode removê-las com:

{{ $json.modifyTime.replace(/"/g, '') }}

2. O nó Data e Hora está retornando uma string entre aspas porque a entrada não está sendo analisada como um objeto de data válido. Tente definir o campo “Entrada” para usar “Detecção automática” ou defina explicitamente o formato de entrada.

A maneira mais rápida de testar qual é o caso: em um nó Código logo após o nó FTP, registre typeof $input.first().json.modifyTime. Se retornar string e o valor incluir aspas, você tem o caso 1. Remova as aspas antes de passar para o nó Data e Hora.

Você também pode fazer isso diretamente no campo de edição:

{{ $json.modifyTime?.replace(/"/g, '').substring(0, 10) }}

Isso lida com a remoção das aspas e a proteção contra valores nulos de uma só vez.

Oi Jay, muito obrigado pelo seu feedback.

Com base nisso, adicionei outro nó Editar Campos imediatamente após o primeiro (veja o PDF anexado) e agora obtenho o formattedDate correto, mesmo ao executar todo o fluxo de trabalho. Ótimo.

No entanto, se eu usar a expressão {{ $json.modifyTime.replace(/"/g, ‘’).substring(0, 10) }} no primeiro nó Editar Campos, então obtenho valores NULL na SAÍDA ao executar todo o fluxo de trabalho.

Nó Editar Campos - problema (debug 2).pdf (192,0 KB)

A saída NULL no primeiro nó Edit Fields ocorre porque a expressão {{ $json.modifyTime.replace("/", "").substring(0, 10) }} executa .replace() em um valor que ainda pode ser um objeto de timestamp bruto (não uma string) naquele ponto. O nó FTP frequentemente retorna modifyTime como um objeto JavaScript Date ou um número, não como uma string, então .replace() falha silenciosamente e retorna null. Tente converter primeiro: {{ new Date($json.modifyTime).toISOString().substring(0, 10) }} - isso força a conversão para uma string ISO apropriada antes de fatiar. Se modifyTime já é uma string formatada como “2026/05/14”, então {{ $json.modifyTime.replace(/\//g, "-") }} (com regex, não apenas “/”) lidaria com todas as barras corretamente.

Pergunta resolvida