Wycofywanie zmian po błędzie i rozwiązywanie konfliktów

Wycofanie optymistycznego dodania (usunięcie elementu) lub usunięcia (przywrócenie elementu) jest proste. Wycofanie aktualizacji jest bardziej złożone: należy przywrócić dokładnie poprzednią wartość. Jeśli element został kilkakrotnie zaktualizowany optymistycznie, trzeba osobno śledzić każdą wcześniejszą wartość, a nie tylko pierwotny stan z serwera.

Rozważmy następujący scenariusz: serwer ma element o wartości Z. Optymistycznie aktualizujesz go do wartości X. Gdy Twoje żądanie jest w toku, inny użytkownik aktualizuje ten sam element na serwerze do wartości Y. Twoje żądanie dociera do serwera, który je odrzuca z powodu konfliktu. Celem wycofania zmian jest wartość Z, ale bieżący stan serwera to Y. Przywrócenie wartości Z nieprawidłowo nadpisałoby wartość Y.

Najbezpieczniejszą strategią wycofywania zmian w przypadku aktualizacji jest ponowne pobranie elementu z serwera po każdym błędzie mutacji, zamiast przywracania migawki zapisanej lokalnie. Dzięki temu zawsze wyświetlasz autorytatywny stan serwera, niezależnie od tego, jakie zmiany mogli równocześnie wprowadzić inni użytkownicy. Ponowne pobranie jest wolniejsze, ale zawsze zapewnia poprawny stan.

Dobrze zaprojektowane API zwraca HTTP 409 Conflict, gdy optymistyczna aktualizacja nie powiedzie się z powodu równoczesnej modyfikacji. Treść odpowiedzi zazwyczaj zawiera bieżący stan serwera. Procedura obsługi błędów powinna wykryć status 409, użyć treści odpowiedzi do zaktualizowania lokalnego stanu bieżącą wartością z serwera oraz poinformować użytkownika, że jego zmiany nie zostały zapisane.

Mutacja idempotentna daje ten sam rezultat przy wielokrotnym zastosowaniu. Projektowanie mutacji jako idempotentnych — za pomocą PUT zamiast POST, przesyłania pełnego stanu zasobu oraz kluczy idempotencji — umożliwia bezpieczne ponawianie operacji po błędzie bez ryzyka wielokrotnego zastosowania zmiany. Znacznie upraszcza to logikę wycofywania zmian.

Dwukrotne kliknięcie przycisku przesyłania może uruchomić dwie identyczne mutacje. Aby temu zapobiec, użyj flagi isSubmitting: ustaw ją na true po rozpoczęciu mutacji, a po jej zakończeniu — niezależnie od powodzenia lub niepowodzenia — przywróć jej poprzednią wartość. Wyłącz element uruchamiający, gdy isSubmitting ma wartość true. Eliminuje to duplikaty mutacji na poziomie interfejsu użytkownika.

W celu deduplikacji po stronie serwera dołącz do każdego żądania mutacji unikatowy nagłówek Idempotency-Key. Wygeneruj jego wartość za pomocą crypto.randomUUID() w chwili rozpoczęcia działania przez użytkownika. Serwer wykrywa zduplikowane klucze i zwraca taką samą odpowiedź jak w przypadku pierwotnego żądania, nie wykonując operacji ponownie.

Gdy mutacja jest w toku, możesz wyświetlić dyskretny wskaźnik informujący, że optymistyczny stan nie został jeszcze potwierdzony: małą pulsującą kropkę, tekst „Zapisywanie...” lub zmniejszone krycie elementu. Przekazuje to informację o niepewności bez blokowania interakcji. Usuń wskaźnik po powodzeniu albo wycofaj zmiany w razie niepowodzenia.

Nieoczekiwane błędy w logice wycofywania zmian, na przykład odwołanie do właściwości wartości undefined podczas przywracania stanu, mogą doprowadzić do awarii komponentu. Owiń komponenty intensywnie korzystające z mutacji w granicę błędów, aby krytyczne błędy wycofywania zmian wyświetlały kontrolowany interfejs błędu zamiast pustego ekranu. Rejestruj te błędy na potrzeby debugowania.

Niezawodna strategia wykrywania konfliktów polega na dołączaniu numeru wersji lub ETag do każdej mutacji. Serwer porównuje wersję przesłaną przez klienta ze swoją bieżącą wersją. Jeśli wersje się różnią, czyli wystąpiła inna aktualizacja, serwer zwraca status 409. To optymistyczna kontrola współbieżności — zakładasz brak konfliktu, ale wykrywasz go, gdy wystąpi.

Logika wycofywania zmian często nie jest testowana, ponieważ trudno symulować awarie sieci. Użyj narzędzi takich jak Mock Service Worker (MSW), aby w testach zwracać odpowiedzi błędów. Napisz osobne testy dla obsługi statusu 409 Conflict, wycofywania zmian po przekroczeniu limitu czasu sieci, deduplikacji dwukrotnych kliknięć oraz spójności stanu po błędzie. To właśnie w tych przypadkach brzegowych często ukrywają się błędy.

Jaki kod statusu HTTP zwraca dobrze zaprojektowane API, gdy optymistyczna aktualizacja nie powiedzie się z powodu równoczesnej modyfikacji wykonanej przez innego użytkownika?

Wycofywanie aktualizacji jest bardziej złożone niż wycofywanie dodawania lub usuwania — po błędzie zawsze ponownie pobieraj dane, aby uniknąć problemów z nieaktualną migawką. Status HTTP 409 Conflict sygnalizuje niepowodzenie optymistycznej kontroli współbieżności; użyj treści odpowiedzi, aby przywrócić bieżący stan serwera. Projektuj mutacje jako idempotentne, aby bezpiecznie je ponawiać. Zapobiegaj wielokrotnemu uruchomieniu za pomocą isSubmitting i kluczy idempotencji po stronie serwera. Testuj ścieżki wycofywania zmian osobno, używając MSW do symulowania błędów.