Mich interessiert, wie erfahrene n8n-Benutzer mit externen APIs umgehen, die langsam werden oder vorübergehend nicht verfügbar sind.
Zum Beispiel:
Workflow
↓
API-Anfrage
↓
Timeout / 503
↓
Wiederholen
↓
Immer noch fehlgeschlagen?
↓
Wiederherstellungs-Workflow
Meine Sorge ist, dass wiederholte Versuche Worker binden und andere Workflows beeinträchtigen könnten.
Wie entscheidest du, wann du erneut versuchst, anstatt sofort zu fehlschlagen?
Verwendest du exponentielles Backoff und Concurrency-Limits?
Wie verhinderst du, dass eine unzuverlässige API den Rest deiner n8n-Instanz beeinträchtigt?
Verwendest du eine separate Warteschlange oder einen Wiederherstellungs-Workflow für diese Fälle?
Beschreibe das Problem/den Fehler/die Frage
Was ist die Fehlermeldung (falls vorhanden)?
Bitte teile deinen Workflow
(Wähle die Knoten auf deiner Canvas aus und verwende die Tastaturkürzel CMD+C/CTRL+C und CMD+V/CTRL+V, um den Workflow zu kopieren und einzufügen.)
Hi @Kabrooks Ein guter Ansatz ist, externe API-Fehler als temporär zu behandeln, bis du weißt, dass sie es nicht sind, aber vermeidet unendliches Wiederholen.
API-Anfrage
↓
Temporärer Fehler?
↓ Ja
Warten + Backoff
↓
Wiederholen
↓
Fehler noch vorhanden?
↓
Wiederherstellungs-Workflow
Ich würde exponentielles Backoff für Dinge wie Timeouts, 429 und 5xx-Fehler verwenden, während permanente Fehler wie ungültige Authentifizierung oder ungültige Eingaben sofort fehlschlagen sollten.
Es hilft auch, eine maximale Anzahl von Wiederholungen und ein Nebenläufigkeitslimit festzulegen, damit eine unzuverlässige API nicht alle deine Worker verbraucht.
Für kritische Workflows würde ich wiederholt fehlgeschlagene Anfragen an einen Wiederherstellungs- oder Dead-Letter-Workflow senden, damit sie später untersucht oder erneut ausgeführt werden können.
Das Hauptziel ist es, den Workflow resilient zu machen, ohne zuzulassen, dass Wiederholungen zu einem Engpass für alles andere werden.
Hi @Kabrooks
Retry On Fail hält die Ausführung für die gesamte Wartezeit aktiv, daher ist ein langer Backoff auf dem Node das, was den Slot verbraucht. Führen Sie den Backoff in einem Wait-Node durch, der über 65 Sekunden eingestellt ist, und schleifen Sie zurück zur HTTP-Anfrage. Über dieser Schwelle lagert n8n die Ausführungsdaten in die Datenbank aus und der Prozess stoppt bis zur Wiederaufnahme, daher kostet Sie ein 5-Minuten-Backoff nichts während des Wartens.
Bei Self-Hosted werden Produktionsausführungen, die das Limit überschreiten, mit N8N_CONCURRENCY_PRODUCTION_LIMIT in FIFO-Reihenfolge in die Warteschlange eingereiht, aber es zählt nur Webhook- und Trigger-Ausführungen. Sub-Workflow- und Fehlerausführungen umgehen es, daher wird ein Recovery-Workflow, der auf diese Weise aufgerufen wird, nicht durch dieses Limit gedrosselt und kann sich trotzdem ansammeln.
Ich würde zwei Dinge hier trennen: Wiederholungslogik und Workflow-Isolation.
Wiederholungen sind nützlich, aber ich würde nicht zulassen, dass eine fehlerhafte API den Hauptworkflow für immer blockiert. Nach einem kleinen Wiederholungsbudget würde ich die fehlgeschlagene Anfrage in einen Wiederherstellungspfad verschieben und den Hauptworkflow entweder sauber beenden oder mit einem klaren Grund fehlschlagen lassen.
Ein Muster, das mir gefällt:
Hauptworkflow bereitet die Payload vor
API-Unter-Workflow behandelt die Anfrage
Der Unter-Workflow gibt entweder Erfolg oder ein normalisiertes Fehlerobjekt zurück
Fehler werden irgendwo nachvollziehbar protokolliert mit Statuscode, Antwortkörper, Ausführungs-ID, ursprünglicher Payload und nächster Aktion
Temporäre Fehler wie Timeouts, 429er und 5xx-Antworten können mit exponentiellem Backoff wiederholt werden. Auth-Fehler, ungültige Eingaben oder Schema-Probleme sollten schnell fehlschlagen.
Das Wichtigste ist, Wiederholungen wiederabspielbar und begrenzt zu machen. Wenn der Workflow bereits etwas in einem anderen System erstellt hat, kann eine Wiederholung des ganzen Flows zu Duplikaten führen. Ich würde lieber den kleinsten riskanten Schritt wiederholen und genug Kontext behalten, um manuell zu recovern, falls nötig.