Hallo, ich habe einen n8n-Workflow, der PostgreSQL aktualisiert und dann eine externe API aufruft. Die schwierige Situation ist, wenn ein Schritt erfolgreich ist und der nächste fehlschlägt.
Wenn PostgreSQL erfolgreich aktualisiert wird, aber der API-Aufruf eine Zeitüberschreitung aufweist, kann der Workflow in einem unsicheren Zustand bleiben. Wenn der gesamte Workflow erneut versucht wird, können auch doppelte Nebenwirkungen entstehen.
Ich denke darüber nach, Status wie „ausstehend
Hallo @Peter_Gavin Ich würde den Workflow zustandsgesteuert und idempotent gestalten, anstatt zu versuchen, den gesamten Prozess in eine große Transaktion zu packen.
Zum Beispiel:
pending
↓
processing
↓
API Call
↓
completed
Speichern Sie einen Idempotency Key für jeden Vorgang, damit ein Wiederholungsversuch sicher bestimmen kann, ob der API-Aufruf bereits ausgeführt wurde.
Für PostgreSQL würde ich eine Unique Constraint verwenden:
INSERT INTO orders (order_id, status)
VALUES ($1, ‘processing’)
ON CONFLICT (order_id) DO NOTHING;
Wenn das API-Timeout auftritt, kann der Recovery-Workflow die API mit demselben Idempotency Key überprüfen, bevor die Anfrage erneut gesendet wird.
Für komplexere Workflows würde ich auch eine Outbox-Tabelle in Betracht ziehen, damit Datenbankänderungen und ausstehende externe Aktionen zuverlässig erfasst werden.
Das Muster, das hier in der Produktion überlebt, ist: Mache die Seiteneffekte einfordbar, bevor sie passieren, und lass niemals zu, dass „unbekannt
@Peter_Gavin Emmas und Jarvis1 haben bereits den wichtigen Teil abgedeckt (die Absicht vor dem Aufruf in die DB schreiben, „unknown
Drei Lücken im obigen Design, alle von der stillen Art.
Die Schaltfläche „Retry
@Anshul_Namdev alle drei sind richtig, und ich bin zur gleichen Docker-Einrichtung zurückgekehrt, um jede einzelne zu überprüfen, anstatt einfach nur zu nicken. Ergebnisse unten, mit den Fixes angewendet auf Workflow 2.
1. Wiederholung bei der abgestürzten Ausführung. Bestätigt. Das Retry-Menü sagt „von Node mit Fehler