Die Daten existieren bereits in der Datenbank, daher ist dies keine Race Condition mit einem kürzlichen Insert.
Was mich verwirrt, ist, dass sich zwischen der ersten und zweiten Ausführung absolut nichts ändert, und doch ist die zweite Ausführung konsistent erfolgreich.
Hat jemand dieses “erste Ausführung schlägt fehl, zweite Ausführung funktioniert”-Verhalten bei MongoDB-Nodes erlebt? Könnte es mit Datentypen (wie ObjectId vs. String), Expression-Evaluierungs-Timing, Ausführungszustand oder einer anderen n8n-spezifischen Besonderheit zusammenhängen?
Du musst sicherstellen, dass die Campaign_ID als ObjectId übergeben wird.
Die zuverlässigste Möglichkeit, ObjectId in n8n zu handhaben, besteht darin, das Abfrageobjekt in einem Code-Node zu erstellen. Dies verhindert, dass n8n deine IDs versehentlich in Strings umwandelt.
Füge einen Code-Node vor deinem zweiten MongoDB-Node hinzu.
Verwende diesen Code:
const leadUserId = $('Edit Fields').first().json.body.args.LeadUserID;
const campaignId = $json._id;
return {
query: {
Customer_ID: leadUserId,
Campaign_ID: { "$oid": campaignId } // Dies teilt MongoDB mit, es als ObjectId zu behandeln
}
};
Referenziere in deinem MongoDB-Node anstatt das JSON manuell zu schreiben die Ausgabe des Code-Nodes: {{ $json.query }}
@alee_Ostovar
Ich hatte ein sehr ähnliches Problem mit Postgres. Soweit ich das verstehen konnte, hatte es mit angehefteten Daten beim Trigger zu tun, besonders wenn der Trigger ein Webhook oder ein „When executed by another workflow
Danke für den Vorschlag. In meinem Fall wird Campaign_IDnicht als MongoDB ObjectId gespeichert. Es wird als String in der Campaign_Members-Collection gespeichert (es ist nur ein Referenzwert, kein echtes ObjectId-Feld).
Deshalb würde das Umhüllen als { "$oid": campaignId } dazu führen, dass die Query nach einer ObjectId sucht, die nicht mit dem gespeicherten String-Wert übereinstimmt.
Danke, ich habe das eigentlich bereits versucht. Ich habe sichergestellt, dass der Webhook-Trigger nicht angeheftet ist, aber leider hat sich das Verhalten nicht geändert.
Eine Workaround, die ich gefunden habe, besteht darin, den Edit Fields (Set)-Knoten durch einen Code-Knoten zu ersetzen, der die gleiche Ausgabe erstellt. Mit dem Code-Knoten funktioniert der Workflow jedes Mal korrekt.
Ich habe auch ein anderes Problem bemerkt, das mit dem Edit Fields-Knoten zusammenhängen könnte: Wenn MongoDB-Dokumente hindurchgeleitet werden, wird die MongoDB _id manchmal in einen Buffer konvertiert, anstatt ihre ursprüngliche Form beizubehalten. Das scheint ein separates Problem mit dem Set/Edit Fields-Knoten selbst zu sein.
Momentан funktioniert die Verwendung eines Code-Knotens als Workaround für beide Probleme, aber es fühlt sich eher danach an, den Bug zu vermeiden, als ihn zu beheben. Ich versuche zu verstehen, warum sich der native Set/Edit Fields-Knoten auf diese Weise verhält.
Ich glaube nicht, dass es ein Datentyp-Mismatch ist, da beide variables als Strings gespeichert sind und die Abfrage auch String-Werte verwendet. Bei einem Typ-Mismatch würde ich erwarten, dass es konsistent fehlschlägt, anstatt nur bei der ersten Ausführung.
Ich konnte das Problem lösen, indem ich den Knoten Edit Fields (Set) durch einen Code-Knoten ersetzt habe. Das funktioniert, aber ich versuche zu verstehen, warum der native Set-Knoten dieses Verhalten überhaupt zeigt.
Durch das Umschließen von {{ $json._id }} in doppelte Anführungszeichen weist du n8n explizit an, die Campaign_ID als String zu behandeln. Wenn MongoDB einen String für ein Feld erhält, das als ObjectId gespeichert ist, gibt es null Ergebnisse zurück, da ein String nicht gleich einem ObjectId ist, auch wenn die Zeichen identisch sind.
Bei der ersten manuellen Ausführung kann der Node möglicherweise den Ausdruck nicht genau wie erwartet auflösen oder die Datenbankabfrage schlägt fehl. Allerdings verwendet der Editor bei der zweiten Ausführung oft die zwischengespeicherte Ausgabe aus dem Ausführungsstatus des vorherigen Nodes.
Das ist genau der verwirrende Teil, und es ist tatsächlich das zweite Problem, auf das ich stoße.
Der Knoten Edit Fields übergibt _id manchmal als [object Object], daher vermutete ich, dass es sich um ein Datentypproblem handelt. Um dies zu überprüfen, habe ich den Wert mit einem Knoten Code unmittelbar nach einem MongoDB-Knoten protokolliert (vor einem Edit Fields). Hier ist die Ausgabe:
Oberflächlich betrachtet scheint es sich um eine primitive Zeichenkette zu handeln. Angesichts des Verhaltens, das ich beobachte, vermute ich jedoch, dass möglicherweise immer noch ein zugrunde liegender BSON-Wrapper oder ein interner Typ/Proxy beteiligt sein könnte, der sich nicht in der Ausgabe des Code-Knotens widerspiegelt. Das würde erklären, warum der MongoDB-Knoten den Wert später als Objekt statt als Zeichenkette behandelt.
Um sicherzustellen, dass es jedes Mal (automatisch oder manuell) ein primitiver String ist, solltest du deinen Ausdruck in einen JavaScript-String-Konstruktor packen.
Durch das Einwickeln des Ausdrucks in String() zwingst du die n8n-Expression-Engine, einen JavaScript-Cast vor der Übergabe des Wertes an den MongoDB-Knoten auszuführen. Dies entfernt alle BSON-Wrapper, Proxies oder Objekt-Metadaten und stellt sicher, dass MongoDB jedes Mal einen Literal-String erhält.
