Décrivez le problème/l’erreur/la question
Pour une raison quelconque, les nœuds épinglés dans mon workflow s’affichent comme « Épinglé » dans l’onglet d’exécution, même si l’exécution n’est pas une exécution de test.
J’ai essayé de dépingler le nœud, mais il s’affiche toujours comme « Épinglé » dans les exécutions après que le nœud a été dépinglé et republié.
Quel est le message d’erreur (le cas échéant) ?
Aucun message d’erreur.
Informations sur votre configuration n8n
- Version de n8n : 2.21.8
- Base de données (par défaut : SQLite) : Cloud par défaut
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) : par défaut
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : n8n cloud
- Système d’exploitation : Windows 11, navigateur Helium Chromium
Bonjour @Evan711
Il semble que votre interface n8n affiche un badge « Épinglé » par erreur, ce qui est probablement une erreur visuelle plutôt qu’un problème avec les données réelles de votre workflow. Bien que vous ayez désépinglé le nœud, votre navigateur ou le service cloud n8n pourrait « mémoriser » l’ancienne configuration à cause d’un problème de cache. Cela signifie que votre workflow s’exécute probablement normalement avec des données réelles, mais l’écran affiche incorrectement le statut épinglé.
Pour résoudre ce problème, vous devriez d’abord essayer un « rafraîchissement complet » de votre navigateur (Ctrl+F5 ou Cmd+Maj+R) pour effacer les informations figées. Si cela ne fonctionne pas, essayez de supprimer le nœud et d’en ajouter un nouveau pour réinitialiser ses paramètres. Vous pouvez vérifier si le problème n’est qu’un bug visuel en téléchargeant votre workflow en tant que fichier JSON ; si le mot « pinData » n’apparaît pas dans ce fichier, alors votre workflow fonctionne parfaitement et le badge « Épinglé » est simplement une erreur d’affichage que vous devriez signaler au support n8n help@n8n.io
@Evan711 l’icône orange/jaune sur « When Executed by Another Workflow » n’est peut-être pas réellement l’indicateur de données épinglées — cela peut aussi être le signal visuel de n8n indiquant que le déclencheur a reçu des données d’entrée du nœud Execute Workflow d’un workflow parent. est-ce que le contenu réellement épinglé s’affiche toujours dans le panneau entrée/sortie de ce nœud quand tu cliques dessus, ou c’est juste l’icône qui indique épinglé ?
Bienvenue @Evan711 dans notre communauté ! Je suis Jay et je suis un créateur vérifié n8n.
L’intuition d’Achamm est juste - l’indicateur orange sur le nœud de déclenchement « When Executed by Another Workflow » ne signifie pas que pinData est actif. C’est le repère visuel de n8n indiquant que le déclencheur a reçu des données en direct du nœud Execute Workflow d’un workflow parent. C’est le comportement attendu pour les sous-workflows.
Pour confirmer qu’il n’y a pas de pinData réelle sur le nœud, téléchargez votre workflow en JSON et recherchez la chaîne pinData dans le fichier. Si elle est absente, les données de ce nœud proviennent à 100 % de données en direct du parent, et non d’épinglettes - le badge est simplement la façon qu’a l’interface utilisateur de montrer que le nœud a reçu une entrée de l’extérieur plutôt que d’être déclenché par son propre déclencheur. Vous pouvez l’ignorer sans risque.
Je poste ici au lieu d’ouvrir un nouveau problème parce que je suis à peu près sûr que je vois la même chose. J’ai eu un problème ce matin où un webhook a été déclenché trois fois. Quand je regarde le nœud webhook dans n8n, non seulement il affiche que les données sont épinglées, mais il montre les données épinglées en sortie au lieu des données réelles qui ont déclenché le webhook. Ce n’est définitivement pas les données d’exécution réelles.
J’ai créé deux vidéos qui montrent cela en action. La première est une démonstration du problème. La deuxième est une démonstration de la raison pour laquelle c’est un problème, où Baserow prétend avoir déclenché le webhook une fois mais n8n prétend que c’était trois fois. Ce problème avec les données épinglées qui s’affichent dans l’onglet Executions rend impossible le dépannage quand les données du webhook sont toujours épinglées dans l’onglet Editor.
J’ai ouvert un problème sur GitHub pour cela, car je suis à peu près sûr que cette communauté n’est qu’un théâtre d’assistance AI-slop copié/collé des aveugles menant les aveugles. Je voulais juste que l’OP sache qu’il n’est pas fou et que des réponses comme « actualiser votre navigateur parce que c’est un problème visuel » ou « c’est bon parce que ce n’est probablement pas réel » peuvent être rejetées.
Merci Adrian ! Ta vidéo démontre exactement le problème auquel je suis confronté. Heureux de savoir que je ne suis pas fou. C’est définitivement un problème avec n8n et non avec mon navigateur.
Je fais face exactement au même problème et cela provoque des erreurs critiques dans nos workflows.
Comme vous l’avez mentionné, les nœuds épinglés saignent maintenant dans les exécutions de production. Cela annule complètement l’objectif de la fonctionnalité, car nous nous appuyons sur les données épinglées uniquement pour tester les flux dans l’éditeur sans affecter le workflow publié en direct. Maintenant, tous nos webhooks/déclencheurs actifs ignorent les données réelles entrantes et utilisent à la place les données mock épinglées.
Ceci est un bug critique pour quiconque exécute n8n en production. Quelqu’un a-t-il trouvé une solution de contournement pour contourner ce problème en attendant un correctif officiel de la part de l’équipe n8n ?
Je ne vois pas les données épinglées se mettre en production. Seulement que le panneau d’exécution affiche les données épinglées au lieu des données de déclenchement réelles. Si vous avez la preuve que vos workflows de production s’exécutent avec des données épinglées, je vous encourage à en faire une vidéo et à l’ajouter au problème que j’ai soulevé et lié ci-dessus. Ou ouvrez un nouveau problème et mettez « critique » ou « urgent » ou quelque chose de similaire dans la ligne d’objet pour que quelqu’un y jette un œil. Si c’est vraiment ce qui se passe, c’est un problème critique, et ils le corrigeront immédiatement.
Mon problème a été fermé en tant que doublon d’une issue précédente qu’ils décrivent comme une régression (une façon élégante de dire « un bug involontaire introduit par une nouvelle fonctionnalité et qui a cassé quelque chose qui fonctionnait déjà »), et qui sera maintenant corrigé dans la version 2.22.6. Ils se sont excusés pour le désagrément.
@adriandotgoins @Thiago_Domingues @Evan711 bienvenue à la communauté n8n.
nouvelle version le 01/06 avec des corrections.
Notes de version | Documentation n8n
@adriandotgoins
Vous avez tout à fait raison. Après avoir effectué des tests plus approfondis en me basant sur votre réponse, j’ai réalisé que le problème est effectivement visuel, exactement comme vous l’avez décrit.
Les vraies données entrantes sont en fait traitées correctement en arrière-plan. Cependant, le facteur aggravant majeur ici est que le panneau d’exécution masque complètement cela. Il affiche le workflow en train de traiter les données épinglées, ce qui signifie que nous perdons complètement la capacité d’inspecter ou d’accéder aux vraies données de production dans les journaux d’exécution.
Ainsi, bien que ce ne soit pas littéralement casser le flux en envoyant des données fictives à la production, cela devient un cauchemar pour le débogage et la surveillance, puisque nous n’avons accès qu’aux résultats visuels des données épinglées.
Je suis vraiment heureux d’apprendre qu’ils l’ont reconnu comme une régression et qu’un correctif est déjà en préparation pour la version 2.22.6. Merci de m’avoir mis sur la bonne piste et d’avoir clarifié le comportement!
Le label « Pinned » dans le journal d’exécution est un enregistrement historique ; il montre ce qui a réellement été exécuté lors de cette exécution spécifique, et non l’état actuel de votre workflow.
Toute exécution déclenchée alors que le nœud était épinglé affichera Pinned de manière permanente, même après avoir déépinglé. Cette partie est attendue et ne changera pas.
La question est de savoir si les nouvelles exécutions après déépinglage + republication affichent également Pinned. Si c’est le cas, essayez d’abord un rechargement forcé (Ctrl+Maj+R) ; parfois le navigateur sert une version en cache du workflow, et le déépinglage ne parvient pas réellement au serveur. Déclenchez ensuite une nouvelle exécution et vérifiez celle-ci spécifiquement.
Si les nouvelles exécutions affichent toujours Pinned après le rechargement forcé, exportez le JSON du workflow et recherchez une clé pinData sur ce nœud. Si elle est toujours présente, le déépinglage n’a pas persisté ; la sauvegarde a échoué silencieusement.
Supprimez-la du JSON, réimportez, republinez, et ce devrait être bon.
Merci pour votre minutie. Le contenu généré par l’IA rend ça dégoûtant
J’ai fait un autre message ici : Pinned Node in execution view is annoying
