Ein Retry-Button ist nur sicher, wenn das System weiß, was bereits geändert wurde.

Warum Lifecycle-Retries schwerer als API-Retries sind

Ein zustandsloser API-Request kann oft wiederholt werden, weil der Server ihn angenommen hat oder nicht. Eine Cluster-Operation kann Server erstellt, Firewallregeln geändert, Zertifikate geschrieben und einen Control-Plane-Node initialisiert haben, bevor die Verbindung abbricht. Der sichtbare Fehler beschreibt die Unterbrechung, nicht zwingend den Zustand der Umgebung.

Recovery muss gewünschte Absicht, dauerhaften Operation-Zustand und beobachteten Provider-/Cluster-Zustand abgleichen. Ohne diesen Vergleich kann ein Replay Ressourcen duplizieren, Trust unerwartet ändern oder einen destruktiven Schritt am falschen Ziel ausführen.

1. Vor der Aktion klassifizieren

Nutzen Sie stabile Klassen wie Voraussetzung, transiente Abhängigkeit, Autorisierung, Kompatibilität, Teilmutation, Cleanup und Abbruch durch Operator. Die Retry-Posture gehört zur Klasse, nicht zu einem beliebigen Exception-Text. Provider-Rate-Limits können nach Backoff wiederholbar sein; eine inkompatible Version braucht einen neuen Plan; unklares Node Replacement zuerst Inspektion.

Zeigen Sie letzten Checkpoint, Ressourcen-IDs und Korrelation. Operators müssen erkennen, ob ein Schritt sicher unverändert, vollständig oder unklar ist. „Unklar“ ist ein legitimer Zustand und muss automatisches Replay blockieren, bis Observation ihn auflöst.

• Retry: denselben idempotenten Schritt nach transientem Fehler wiederholen
• Resume: ab bestätigtem Checkpoint fortsetzen
• Compensate: definierte Gegenaktion ausführen
• Cleanup: Restressourcen entfernen und Versuch schließen
• Replan: neuen Vorgang erzeugen, wenn sich Absicht oder Voraussetzungen ändern

2. Operation-Zustand dauerhaft speichern

Speichern Sie ID, Intent, Actor, Ziel, Planrevision, Schritte, Attempts, Leases, Checkpoints, Artefakte und Terminalergebnis außerhalb des ausführenden Prozesses. Browser-Refresh oder Agent-Neustart dürfen nicht löschen, was freigegeben und beobachtet wurde.

Begrenzte Leases verhindern parallele Mutation. Nach Lease-Ablauf wird das Ziel vor Neuvergabe abgeglichen. Vor einer Fortsetzung müssen Arbeitszuweisung, Checkpoints, Artefakte und Agent-Zustand gemeinsam abgeglichen werden.

3. Idempotenz an der Ressourcengrenze entwerfen

Ein Idempotency Key verhindert doppelte API-Annahme, macht aber Provider- oder Hostbefehle nicht automatisch idempotent. Verwenden Sie stabile externe IDs, Read-before-write-Abgleich und Postcondition-Checks. Ein Schritt ist abgeschlossen, wenn das beabsichtigte Ergebnis beobachtet wurde – nicht nur bei Exit Code null.

Für nicht wiederholbare Arbeit braucht es Checkpoints vor und nach dem kritischen Übergang sowie explizite Bestätigung bei unklarem Ergebnis. Destruktive Aktionen werden an Zielidentität, Planrevision und Ablaufzeit gebunden.

4. Recovery als Produktpfad testen

Injizieren Sie Fehler in einer disponiblen Umgebung: Executor zwischen Checkpoints beenden, Registry blockieren, Credential entziehen, Provider drosseln, Node ausfallen lassen und Cleanup unterbrechen. Prüfen Sie, dass der Vorgang einen wahrheitsgemäßen Zustand erreicht und nur sichere Aktionen anbietet.

Die Abnahme speichert injizierten Fehler, stabilen Code, Checkpoint, Recovery-Aktion, Endzustand, Restressourcenprüfung und Operator-Notiz. Dieser Nachweis ist belastbarer als eine allgemeine Resilienzbehauptung.

5. Recovery zwischen Personen übertragbar machen

Ein guter Fehlerdatensatz erlaubt die sichere Übernahme durch eine Person, die nicht dabei war. Plan, redigierte Logs, stabiler Code, Ressourcen-IDs, Checkpoint, Hashes, Versuche und nächste Aktion bleiben erhalten. Vermeiden Sie Anweisungen, die eine nicht aufgezeichnete Terminal-Session voraussetzen.

Schließen Sie fehlgeschlagene Versuche bewusst: zurück zur Baseline, mit bekannter Abweichung nutzbar oder Eskalation erforderlich. Diese Klarheit verhindert, dass alte Teiloperationen zum versteckten Risiko der nächsten Änderung werden.