Duplizierte Nebenwirkungen bei Webhook-Wiederholungen verhindern

Ein Client-Flow hat für einen Formular-Submit 3 HubSpot-Notizen erstellt, weil der Absender erneut versucht hat.

Das hat mir dabei geholfen, das Problem zu beheben:

Grab eine stabile ID (ihren Idempotenz-Schlüssel oder Hash von external_id + event type). Vor jedem Create/Update-Node nach diesem Schlüssel in einem kleinen Store suchen. Wenn er vorhanden ist, 200 zurückgeben und beenden. Wenn nicht, zuerst den Schlüssel schreiben, dann die Nebeneffekte ausführen.

Beschriften Sie auch, welche Nodes schreiben vs. lesen, in der Notiz. Du wirst es vergessen.

Nicht perfekt für jeden Fall, aber das hat die doppelten Notizen beseitigt.

@blessoftware - der atomare Schritt ist die richtige Lösung, und ich würde ihn auf drei Kanten erweitern, die in der Produktion zubeißen.

Schlüsselwahl. „Ihr Idempotenzschlüssel

@InvestigatorSuper216 Guten Tag!
Die Lösungen von @blessoftware und @InvestigatorSuper216 sind äußerst präzise, technisch fundiert und entsprechen vollkommen den Best Practices für verteilte Systeme.

Faktencheck und technische Highlights

Atomarer Betrieb @blessoftware ist völlig korrekt. Ein Standard-„Check-then-Write

Ein Punkt, den ich noch hinzufügen würde: „Den Schlüssel zuerst schreiben

@daniel_Samuel, eine Korrektur: Data Tables unterstützen derzeit keine UNIQUE-Beschränkung für benutzerdefinierte Spalten, daher funktioniert dieser Teil nicht. Behalten Sie den Postgres-Unique-Key-Ansatz für den atomaren Anspruch bei.

Löschen Sie den Schlüssel auch nicht nur, weil der HubSpot-Knoten fehlschlägt. Ein Timeout kann auftreten, nachdem HubSpot die Notiz erstellt hat. Das Löschen des Schlüssels ermöglicht dann dem Retry, eine weitere zu erstellen. Das ist der Fall für den oben beschriebenen poison/review-Status, nicht für die automatische Wiederholung.

Für die Webhook-Antwort stellen Sie „Respond to Using ‘Respond to Webhook’ Node

Der dauerhafte Schreibzugriff vor der Rückgabe von 200 ist hier die Schlüsselgrenze.

In meiner Erfahrung mit Inistate behandle ich den Webhook als Beginn eines langfristigen Vorgangs, anstatt einfach ein „gesehen/nicht gesehen

Ein Sonderfall, den ich hier hinzufügen würde: Stellen Sie sicher, dass der „Schlüssel prüfen → Schlüssel schreiben