Fehlerbehandlung
Teil von Doppelte Aktionen verhindern
Schutz vor Duplikaten vor dem Produktivstart testen
Prüfen Sie Duplikatschutz mit Wiederholungen, parallelen Läufen, verlorenen Antworten und neuen Vorgängen. Mit Soll-Matrix für Testdaten.
Testen Sie mit Testdaten, ob ein wiederholter Auftrag keine zweite Wirkung erzeugt und ein berechtigter neuer Auftrag weiterhin funktioniert. Prüfen Sie die Ergebnisse im Zielsystem; ein erfolgreicher Workflow-Lauf allein belegt keinen wirksamen Duplikatschutz.
Sollverhalten festlegen
Wählen Sie eine konkrete Aktion, etwa das Anlegen eines Rechnungsentwurfs. Legen Sie fachlichen Schlüssel, erwartete Ergebniskennung und erlaubte Wiederaufnahme fest. So lässt sich jeder Versuch gegen ein klares Soll prüfen.
Testfall / Erwartete Wirkung
- Erster gültiger Auftrag
- Ein Ergebnis und eine zugeordnete Ergebniskennung.
- Derselbe Auftrag erneut
- Keine zweite Wirkung; das vorhandene Ergebnis bleibt zuordenbar.
- Zwei gleichzeitige Läufe mit demselben Schlüssel
- Höchstens ein fachliches Ergebnis.
- Antwort nach erfolgreicher Anlage verloren
- Bestehendes Ergebnis wird zugeordnet oder der Fall bleibt sichtbar ungeklärt.
- Gleicher Schlüssel mit anderen fachlichen Parametern
- Sichtbarer Konflikt statt stiller Überschreibung.
- Neuer berechtigter Auftrag mit ähnlichen Daten
- Ein eigenes Ergebnis ist möglich.
Gleichzeitige Läufe prüfen
Zwei nacheinander gestartete Versuche zeigen nicht, ob zwei Worker gleichzeitig „noch nicht vorhanden“ lesen. Starten Sie daher zwei Läufe mit demselben Schlüssel, sodass sie sich vor der Anlage überschneiden können. Prüfen Sie danach Objekte und Kennungen im Zielsystem.
Eine vorgelagerte Existenzabfrage allein reicht dafür nicht aus. Speichert PostgreSQL den gemeinsamen Zustand, kann eine passende Eindeutigkeitsregel zusammen mit ON CONFLICT DO NOTHING eine zweite Einfügung verhindern. Eine externe Aktion ist nur geschützt, wenn auch an ihrer Grenze eine geeignete Sicherung besteht.
Fehler vor und nach der Aktion unterscheiden
Simulieren Sie einen Fehler vor dem Zielaufruf und eine verlorene Antwort nach erfolgreichem Zielaufruf. Im ersten Fall muss eine zulässige Wiederaufnahme möglich sein, im zweiten darf sie keine zweite Anlage auslösen. Erfassen Sie getrennt, ob die Aktion nicht begonnen hat, noch läuft, abgeschlossen ist oder ihr Ergebnis unklar bleibt.
Prüfen Sie auch spätere Wiederholungen. Stripe kann API-Idempotenzschlüssel entfernen, sobald sie mindestens 24 Stunden alt sind; danach kann eine Anfrage mit demselben Schlüssel erneut ausgeführt werden. Die eigene Zustandsaufbewahrung muss zum tatsächlichen Wiederholungsfenster des Ablaufs passen.
Dokumentieren Sie je Test Eingabe, Schlüssel, erwartete Wirkung, beobachtete Zielobjekte und Reaktion des zweiten Laufs. Wiederholen Sie die kritischen Fälle nach Änderungen an Schlüsselbildung, Statusspeicherung, API-Aufruf oder Wiederholungsregeln. Ein unklarer Fall braucht einen festgelegten Prüfweg, bevor der Ablauf produktiv genutzt wird.
