Bei Fehlern zurücksetzen und Konflikte lösen

Das Zurücksetzen einer optimistischen Erstellung (das Element entfernen) oder eines optimistischen Löschvorgangs (das Element wiederherstellen) ist unkompliziert. Das Zurücksetzen einer Aktualisierung ist komplexer: Sie müssen den exakt vorherigen Wert wiederherstellen. Wenn das Element mehrfach optimistisch aktualisiert wurde, müssen Sie jeden vorherigen Wert separat nachverfolgen und nicht nur den ursprünglichen Serverzustand.

Betrachten Sie folgendes Szenario: Auf dem Server hat ein Element den Wert Z. Sie aktualisieren es optimistisch auf X. Während Ihre Anfrage noch läuft, aktualisiert eine andere Person dasselbe Element auf dem Server auf Y. Ihre Anfrage trifft ein und wird vom Server abgelehnt (Konflikt). Ihr Rollback-Ziel ist Z, der aktuelle Zustand auf dem Server ist jedoch Y. Wenn Sie Z wiederherstellen, würden Sie Y fälschlicherweise überschreiben.

Die sicherste Strategie zum Zurücksetzen von Aktualisierungen besteht darin, das Element bei jedem Mutationsfehler vom Server neu zu laden, anstatt einen lokal erfassten Snapshot wiederherzustellen. Dadurch zeigen Sie garantiert den maßgeblichen Serverzustand an, unabhängig davon, welche Änderungen andere Personen zwischenzeitlich vorgenommen haben. Das erneute Laden ist langsamer, aber immer korrekt.

Eine gut konzipierte API gibt HTTP 409 Conflict zurück, wenn eine optimistische Aktualisierung aufgrund einer gleichzeitigen Änderung fehlschlägt. Der Antworttext enthält normalerweise den aktuellen Serverzustand. Ihre Fehlerbehandlung sollte den Status 409 erkennen, den Antworttext verwenden, um den lokalen Zustand mit dem aktuellen Wert des Servers zu aktualisieren, und die Person darüber informieren, dass ihre Änderungen nicht gespeichert wurden.

Eine idempotente Mutation liefert dasselbe Ergebnis, wenn sie mehrfach angewendet wird. Wenn Sie Mutationen idempotent gestalten (indem Sie PUT statt POST verwenden, den vollständigen Ressourcenzustand übertragen und Idempotenzschlüssel verwenden), können Sie sie bei einem Fehler sicher wiederholen, ohne die Änderung doppelt anzuwenden. Dadurch wird die Rollback-Logik deutlich einfacher.

Doppelklicks auf eine Übermittlungsschaltfläche können zwei identische Mutationen auslösen. Verhindern Sie dies mit einem isSubmitting-Flag: Setzen Sie es beim Start der Mutation auf true und nach ihrem Abschluss wieder zurück – unabhängig davon, ob sie erfolgreich war oder fehlgeschlagen ist. Deaktivieren Sie das auslösende Element, wenn isSubmitting den Wert true hat. Dadurch werden doppelte Mutationen auf der Ebene der Benutzeroberfläche verhindert.

Für die serverseitige Deduplizierung fügen Sie jeder Mutationsanfrage einen eindeutigen Idempotency-Key-Header hinzu. Erzeugen Sie ihn mit crypto.randomUUID(), sobald die Person die Aktion startet. Der Server erkennt doppelte Schlüssel und gibt dieselbe Antwort wie bei der ursprünglichen Anfrage zurück, ohne den Vorgang erneut anzuwenden.

Während eine Mutation läuft, können Sie durch einen dezenten Hinweis anzeigen, dass der optimistische Zustand noch nicht bestätigt ist: etwa durch einen kleinen pulsierenden Punkt, den Text "Wird gespeichert..." oder eine verringerte Deckkraft des Elements. So vermitteln Sie die Unsicherheit, ohne die Interaktion zu blockieren. Entfernen Sie den Hinweis bei Erfolg oder setzen Sie den Zustand bei einem Fehler zurück.

Unerwartete Fehler in der Rollback-Logik (z. B. beim Zugriff auf Eigenschaften von undefined während der Zustandswiederherstellung) können die Komponente zum Absturz bringen. Umschließen Sie Komponenten mit vielen Mutationen mit einer Error Boundary, damit schwerwiegende Rollback-Fehler eine angemessene Fehleroberfläche statt eines leeren Bildschirms anzeigen. Protokollieren Sie diese Fehler zur Fehlersuche.

Eine zuverlässige Strategie zur Konflikterkennung besteht darin, jeder Mutation eine Versionsnummer oder ein ETag beizufügen. Der Server vergleicht die vom Client gesendete Version mit seiner aktuellen Version. Wenn sie sich unterscheiden (also eine andere Aktualisierung stattgefunden hat), gibt er 409 zurück. Dies ist optimistische Nebenläufigkeitskontrolle: Sie gehen davon aus, dass kein Konflikt vorliegt, erkennen ihn aber, sobald er auftritt.

Rollback-Logik wird häufig nicht getestet, weil sich Netzwerkfehler nur schwer simulieren lassen. Verwenden Sie Tools wie Mock Service Worker (MSW), um in Tests Fehlerantworten zurückzugeben. Schreiben Sie explizite Tests für die Behandlung von 409 Conflict, das Rollback nach einem Netzwerk-Timeout, die Deduplizierung bei Doppelklicks und die Zustandskonsistenz nach einem Fehler. In diesen Randfällen verbergen sich häufig Fehler.

Welchen HTTP-Statuscode gibt eine gut konzipierte API zurück, wenn eine optimistische Aktualisierung aufgrund einer gleichzeitigen Änderung durch eine andere Person fehlschlägt?

Das Zurücksetzen einer Aktualisierung ist komplexer als das Zurücksetzen einer Erstellung oder eines Löschvorgangs. Laden Sie bei einem Fehler immer die Daten neu, um Probleme durch veraltete Snapshots zu vermeiden. HTTP 409 Conflict signalisiert Fehler bei der optimistischen Nebenläufigkeitskontrolle; verwenden Sie den Antworttext, um den aktuellen Serverzustand wiederherzustellen. Gestalten Sie Mutationen für sichere Wiederholungen idempotent. Verhindern Sie doppelte Auslösungen mit isSubmitting und serverseitigen Idempotenzschlüsseln. Testen Sie Rollback-Pfade ausdrücklich, indem Sie mit MSW Fehler simulieren.