Lors de l’exécution du flux de travail, le nœud Edit Fields affiche NULL pour modifyTime (expression : {{ $json.modifyTime.substring(0, 10) }} ). Lors de l’exécution manuelle du nœud, la sortie est correcte - veuillez consulter la capture d’écran jointe.
Veuillez partager votre flux de travail pour fournir plus de contexte
@Massimiliano_Bellini semble que l’un des éléments qui arrive n’ait pas modifyTime défini, donc la substring explose sur undefined. Les exécutions manuelles utilisent des données épinglées mais les exécutions complètes parcourent chaque élément. Protégez-le :
{{ ($json.modifyTime ?? '').substring(0, 10) }}
vérifiez aussi le nœud qui alimente, il retourne probablement des éléments où ce champ manque
@Massimiliano_Bellini , vous pouvez aussi ajouter une vérification de null
{{ $json.modifyTime ? $json.modifyTime.substring(0, 10) : null }}
Salut à tous, petite mise à jour : en tant que solution de contournement, j’ai ajouté un nœud Date et Heure pour formater la date - en veillant à ce que les autres entrées du nœud soient également incluses dans sa sortie. Ça fonctionne bien.
J’ai toujours une question : ai-je fait une erreur dans mon workflow précédent, ou y a-t-il un bug dans le nœud Edit Fields (Set) version 3.4 ?
Excellent diagnostic, @Massimiliano_Bellini ! Je suis content que la solution avec le node Date & Time vous ait permis d’avancer.
Pour répondre à votre question - il s’agit probablement d’une incohérence de données plutôt que d’un bug dans Edit Fields lui-même. Voici ce qui se passe probablement :
Le node FTP list retourne les fichiers du serveur FTP, et certains de ces fichiers peuvent ne pas avoir de valeur modifyTime définie côté serveur (null ou absent). Lorsque vous exécutez le node manuellement via « Execute Step », vous ne regardez probablement que le premier élément dans la sortie de test, qui se trouve avoir un modifyTime valide. Mais lors d’une exécution complète du workflow, les 9 éléments sont traités, et certains d’entre eux n’ont pas ce champ - c’est pourquoi vous obtenez NULL.
L’expression {{ $json.modifyTime.substring(0, 10) }} génère une TypeError lorsque modifyTime est null ou undefined, et n8n retourne silencieusement null pour ce champ dans ce cas.
La solution appropriée est de vous protéger contre null, exactement comme d’autres l’ont suggéré :
{{ ($json.modifyTime ?? '').substring(0, 10) }}
Ou si vous voulez préserver null pour les fichiers sans date de modification :
{{ $json.modifyTime ? $json.modifyTime.substring(0, 10) : null }}
Votre approche avec le node Date & Time fonctionne également bien car elle force n8n à gérer le formatage datetime dans une étape dédiée qui peut traiter le cas null plus gracieusement.
Si cela clarifie les choses, n’hésitez pas à marquer l’une des réponses comme Solution afin que d’autres ayant le même problème FTP + champ null puissent trouver ce fil !
Bonjour Jay, merci d’avoir pris le temps d’examiner mon problème. Je remercie également les autres qui m’ont envoyé leurs avis et suggestions. D’après ce que vous avez tous dit, je suis porté à croire que ce que j’éprouve n’est pas vraiment un bug. Cependant… le nœud FTP retourne une valeur « modifyTime » correctement définie pour chaque élément/fichier. Veuillez jeter un œil au nouveau test que je viens de lancer — vous pouvez voir que lorsque vous exécutez le workflow, la date formatée est entourée de caractères "
Edit Fields node - issue (debug).pdf (258,5 KB)
@Massimiliano_Bellini Merci de partager le PDF de debug ! Ce comportement de wrapping de guillemets est vraiment révélateur.
Quand la date formatée s’affiche comme "2025-01-01" (avec des caractères de guillemets littéraux), cela signifie généralement l’une de deux choses :
1. La valeur du nœud FTP est une chaîne JSON qui contient déjà des guillemets échappés. Par exemple, la valeur brute pourrait être "2025-01-01" en tant que chaîne plutôt que 2025-01-01. Vous pouvez les supprimer avec :
{{ $json.modifyTime.replace(/"/g, '') }}
2. Le nœud Date & Time génère une chaîne entre guillemets parce que l’entrée n’est pas analysée comme un objet date approprié. Essayez de définir le champ « Input » pour utiliser « Auto-detect » ou définissez explicitement le format d’entrée.
Le moyen le plus rapide de tester lequel c’est : dans un nœud Code juste après le nœud FTP, loggez typeof $input.first().json.modifyTime. S’il retourne string et que la valeur inclut des guillemets, vous avez le cas 1. Supprimez les guillemets avant de passer au nœud Date & Time.
Vous pouvez aussi le faire inline dans Edit Fields :
{{ $json.modifyTime?.replace(/"/g, '').substring(0, 10) }}
Cela gère à la fois la suppression des guillemets et la vérification de null en une seule opération.
Bonjour Jay, merci beaucoup pour tes commentaires.
En me basant sur cela, j’ai ajouté un autre nœud Edit Fields immédiatement après le premier (voir le PDF joint) et j’obtiens maintenant la formattedDate correcte même quand j’exécute l’ensemble du workflow. C’est bon.
En revanche, si j’utilise l’expression {{ $json.modifyTime.replace(/"/g, ‘’).substring(0, 10) }} dans le premier nœud Edit Fields, j’obtiens des valeurs NULL dans OUTPUT quand j’exécute l’ensemble du workflow.
Edit Fields node - issue (debug 2).pdf (192.0 KB)
La sortie NULL dans le premier nœud Edit Fields se produit parce que l’expression {{ $json.modifyTime.replace("/", "").substring(0, 10) }} exécute .replace() sur une valeur qui pourrait encore être un objet timestamp brut (pas une chaîne de caractères) à ce stade. Le nœud FTP retourne souvent modifyTime en tant qu’objet JavaScript Date ou nombre, pas une chaîne de caractères, donc .replace() échoue silencieusement et produit null. Essayez de convertir d’abord : {{ new Date($json.modifyTime).toISOString().substring(0, 10) }} - cela la force à une chaîne ISO appropriée avant de la découper. Si modifyTime est déjà une chaîne formatée comme “2026/05/14”, alors {{ $json.modifyTime.replace(/\//g, "-") }} (avec une expression régulière, pas juste “/”) gérerait correctement toutes les barres obliques.
