Hallo zusammen,
Ich möchte eine Umgebung haben, in der ich A<->B habe. Wenn A live ist, kann ich an B arbeiten und umgekehrt.
Wenn ich den Workflow klonen, um eine Kopie der neuesten Version zu haben, muss ich plötzlich fast alle meine Nodes aktualisieren. Fast 100. Zum Beispiel die Supabase-Logging-Nodes. Aber es ist nichts falsch, ich muss sie nur öffnen, dann werden die Datenbanktabellen geladen und ich kann sie wieder schließen. Aber es ist ein langsamer Prozess und ich muss das oft machen. Wenn ich das nicht mache, kann ich den Workflow nicht einmal veröffentlichen. Fühlt sich an wie ein Bug im n8n-System. Vielleicht ist meine Anwendung zu groß für n8n geworden. Aber kennt jemand eine Lösung dafür?
Hast du schon versucht, Import/Export statt Klonen/Duplizieren zu verwenden?
Du kannst auch alle Knoten des problematischen Workflows kopieren und in einen neuen Workflow einfügen.
Hat das geholfen?
Danke für deine schnelle Antwort!
#1 Leider scheint die Git-Lösung nur im Business-Plan verfügbar zu sein, was ein monatliches „Upgrade“ mit deutlich höheren Kosten erfordern würde. Ehrlich gesagt, kommt mir das sehr seltsam vor.
#2 Gibt es eine n8n-CLI?
#3 Meine Erfahrung mit kleineren, aufgeteilten (Unter-)Workflows ist, dass die Organisation dadurch schlechter wird und die Übersicht viel schwieriger ist. Ich muss ständig suchen:
Besonders beim A/B-Testing. Wenn ich von einem Workflow auf drei oder vier Workflows mit A/B-Varianten wechsle, kann ich schnell bei acht verschiedenen Workflows und Versionen landen.
Ich sehe im Moment ehrlich gesagt hauptsächlich Nachteile. Trotzdem schätze ich deinen Rat sehr!
@Bart_Sch
Es sieht so aus, als ob du deine Anmeldeinformationen erneut eingeben solltest.
Der Code-Knoten benötigt keine Anmeldeinformationen, daher ist er davon nicht betroffen…
Es sind gar keine Zugangsdaten. Es geht im Grunde darum, den Knoten zu öffnen und wieder zu schließen. Dann ist es behoben. Aber meiner Meinung nach sollte das automatisch und ohne Eingreifen geschehen.
Entschuldigung, ich dachte, ich hätte erwähnt, dass es eine Cloud-Instanz ist. Das habe ich aber nicht. Leider kann ich das nicht nutzen.
Glaubst du, es wird dann funktionieren? Und warum?
Was zum F. Ich habe auch Knoten mit unterschiedlichen Zugangsdaten. Das Klonen verändert also den Workflow. Was für ein Amateur-Tool 
Oh je, und als ich exportiert und importiert habe, hat sich der Name ebenfalls exakt in denselben Workflow-Namen geändert. Fast hätte ich meinen funktionierenden Workflow kaputtgemacht…
Entschuldigung für all die Nachrichten. Bei mir funktioniert weder der Download noch der Import, und es gibt noch weitere Konflikte, da alles exakt geklont wird.
Hi @Bart_Sch, danke für die Klarstellung.
Ich denke, das zugrundeliegende Problem könnte immer noch mit den Anmeldedaten zusammenhängen, aber nicht in dem Sinne, dass der Anmeldedatenwert falsch ist. Da das Öffnen und Schließen des Knotens es wieder zum Funktionieren bringt, wirkt es eher so, als würde der geklonte Knoten den Anmeldedatenzustand nicht korrekt auflösen oder aktualisieren, bis die Benutzeroberfläche ihn neu lädt.
Der Code-Knoten selbst könnte also in Ordnung sein, während die Anmeldedatenbindung nach dem Klonen der Teil zu sein scheint, der steckenbleibt.
Danke nochmal für die Details, das hilft sehr dabei, das Problem einzugrenzen.
Ich bin schon mal auf das gleiche Problem gestoßen, und das Einzige, das mir meine Ruhe bewahrt hat, war die Neuauswahl der Anmeldedaten auf einem Node, dann das Duplizieren dieses korrigierten Nodes und das Kopieren seiner JSON über die fehlerhaften. Es fühlt sich immer noch etwas hacky an, aber es hat die Routinearbeit erheblich reduziert. Es lässt mich vermuten, dass die Clone-Funktion einfach vergisst, die Credential-States im Hintergrund zu synchronisieren.
@Bart_Sch
Eine weitere sichere Lösung wäre, den geklonten Workflow in Blöcken statt alle defekten Knoten auf einmal zu reparieren. Ich würde einen neuen leeren Workflow erstellen und dann eine kleine Gruppe von Knoten aus dem ursprünglichen Workflow kopieren, zum Beispiel einen Bereich oder eine Integration gleichzeitig. Nach dem Einfügen jedes Blocks würde ich die Anmeldedaten nur einmal für diesen Block erneut auswählen, testen und dann mit dem nächsten Block fortfahren. Dies ist langsamer als ein vollständiger Klon, aber sicherer als die manuelle Bearbeitung von 100 Knoten oder die Änderung der exportierten JSON auf einmal, besonders bei Cloud. Es hilft auch zu identifizieren, welcher Knotentyp oder welche Integration nach dem Klonen seinen Anmeldedaten-Status verliert.
Ich würde den ursprünglichen Workflow unverändert lassen, den Ersatz unter einem temporären Namen erstellen, jeden Bereich testen und nur dann Production-Traffic wechseln, nachdem die neu erstellte Version vollständig validiert wurde.
Danke für die Hilfe, sehr geschätzt.
Nach einigen Tests gehe ich doch für die Option Download > Import:
Ich muss aufpassen, weil sich der Name zum ursprünglichen Workflow ändert, von dem ich hergekommen bin. Und mein Flow hat einen Webhook, der nach dem Import auf 1 Node geändert und aktualisiert werden muss, aber das ist viel besser als das Wiedereröffnen aller Nodes, wie ich anfangs gemacht habe.
Fühlt sich immer noch ein bisschen wie ein Workaround an und es ist irgendwie seltsam, dass es keine echte unterstützte Test/Prod-Methode gibt. Ich dachte, dieses Produkt ist für Enterprise. Leider ist die Git-Option im teureren Plan enthalten.
Zweite Option wäre vielleicht, eine Pipeline zu bauen und zu klonen und via API oder MCP zu aktualisieren, aber dafür habe ich momentan nicht so viel Zeit, das herauszufinden. Ich hätte mir eine eingebaute Methode gewünscht.
Nochmal danke an alle.
Bart
