Décrire le problème/l’erreur/la question
Bonjour à tous,
J’ai commencé à voir ce message d’erreur après avoir mis à niveau vers la version 2.20.6. Avez-vous une idée sur comment le corriger ?
Merci d’avance
Bienvenue @Gonzalo_Romero_Herna
Veuillez partager votre flux de travail et indiquer sur quel nœud l’erreur s’est produite
Merci @kjooleng !! En fait, c’est en rafraîchissant simplement mon canvas que ça se produit ! Aucune exécution de workflows n’est nécessaire pour déclencher l’erreur !
Bonjour,
Cela m’aiderait si tu pouvais partager le message d’erreur exact ou une capture d’écran. Puisque le problème a commencé après la mise à jour vers la version 2.20.6, cela pourrait être lié à un changement de configuration, une incompatibilité de dépendance, ou un problème de compatibilité introduit dans cette version.
De plus, mentionner :
-
ton système d’exploitation,
-
ta méthode de déploiement,
-
et si la mise à jour a été effectuée proprement ou sur place
faciliterait le dépannage du problème pour les autres.
Merci !
Pouvez-vous consulter les journaux du conteneur n8n juste après l’apparition de l’erreur ? Exécutez docker logs n8n --tail 50 et partagez les lignes d’erreur - « Source control failed to connect » (Échec de la connexion du contrôle de source) s’affiche généralement en tant que rejet de clé SSH ou une incompatibilité de format d’URL Git en dessous. Confirmez également : la clé publique SSH que vous avez ajoutée dans Paramètres > Contrôle de source est-elle toujours correctement déployée sur les clés de déploiement de votre référentiel GitHub/GitLab ? Après les mises à niveau, la clé stockée dans les paramètres de n8n doit parfois être réenregistrée.
Hé @David_Warner, Merci beaucoup pour votre réponse, en fait je reçois l’erreur directement de l’interface utilisateur comme je l’ai partagé dans la capture d’écran. Cependant, j’ai aussi remarqué cette erreur dans les outils de développement du navigateur chaque fois que l’erreur se déclenche :
J’utilise une instance auto-hébergée déployée sur ECS Fargate
Merci beaucoup
Salut @nguyenthieutoan, merci pour ton commentaire ! c’est intéressant !! En fait, j’ai oublié de mentionner que j’ai aussi upgrader ma licence de community à business. Je ne sais pas si c’est lié mais peut-être que ça pourrait l’être. Pour l’instant, je n’ai aucune sorte de configuration ssh 
!!!
Cela explique beaucoup de choses - si aucune clé SSH n’est configurée, n8n ne peut pas s’authentifier auprès du dépôt Git, la fonctionnalité Source Control échoue immédiatement à chaque tentative de connexion. Allez dans Paramètres > Source Control > SSH Key et cliquez sur « Generate » pour créer une nouvelle paire de clés ED25519. n8n vous affichera la clé publique - copiez-la et ajoutez-la en tant que Deploy Key dans votre dépôt GitHub/GitLab (Paramètres > Deploy Keys). Collez ensuite l’URL SSH de votre dépôt (pas HTTPS) dans le champ Repository URL. La mise à niveau de la licence vers Business ne devrait pas causer cela, mais assurez-vous de vous reconnecter après la mise à niveau, car les paramètres Source Control peuvent être réinitialisés.
Génial @nguyenthieutoan !! Je vais le faire de cette manière !. En y réfléchissant, est-ce que n8n essaie de s’authentifier automatiquement à Git par défaut ?
Oui - n8n utilise la clé SSH que vous configurez dans les paramètres du contrôle de source pour s’authentifier automatiquement à chaque pull/push. Il ne demande pas les identifiants à l’exécution. La clé doit être ajoutée à votre fournisseur Git (GitHub, GitLab, etc.) en tant que clé de déploiement avec accès en écriture si vous souhaitez effectuer un push depuis n8n. Si la clé est en lecture seule (clé de déploiement sans accès en écriture), le pull fonctionne mais le push échouera.