Czy ta wysyłka, której minął czas, naprawdę zapisała Twoją pracę?

Błąd przeglądarki dowodzi, że odpowiedź nie dotarła, a nie że zapis się nie udał. Zapisz tekst, znajdź wynik w aplikacji, a potem zdecyduj, czy ponowna próba jest bezpieczna.

Przycisk się kręci, karta pokazuje błąd, a formularz, który wypełniałeś przez dziesięć minut, zniknął. Nie wiesz, czy zapis dotarł, zanim połączenie padło. Traktowanie tej niewiadomej jako porażki to właśnie sposób, w jaki powstają zduplikowane komentarze, podwójne zamówienia i powtarzane zgłoszenia do pomocy.

Odzyskuj w ustalonej kolejności: zachowaj tekst, znajdź wynik i dopiero wtedy zdecyduj, czy drugie wysłanie jest dozwolone.

Zacznij od tekstu i znacznika czasu

Skopiuj treść ze strony, zanim dotkniesz czegokolwiek innego, w tym szkicu, który przeglądarka wciąż trzyma w polu. Zapisz godzinę, stronę, na której byłeś, i wykonaną akcję, bo właśnie te trzy szczegóły umożliwiają resztę dochodzenia. Jeśli karta jest nadal otwarta, zostaw ją otwartą, dopóki nie przeczytasz wpisu sieciowego. Zapisanie tekstu nic nie kosztuje, a jego utrata kosztuje całe zadanie.

Następnie rozdziel dwa rodzaje awarii, które naprawdę możesz zaobserwować. Połączenie zerwane w połowie żądania i serwer, który odpowiedział błędem, wyglądają w panelu sieci inaczej, i tylko drugi mówi coś o decyzji aplikacji.

Szukaj wyniku w widoku samej aplikacji

Odśwież widok odczytu, który pokazałby wynik: listę komentarzy, historię zamówień, kolejkę zgłoszeń albo rekord, który edytowałeś. Porównuj według konta, celu, czasu i treści, a nie według najnowszego wpisu, bo ktoś inny mógł napisać po tobie. Przy zadaniu w tle poszukaj istniejącego odwołania i jego statusu, zamiast tworzyć nową operację jako test łączności.

Jeśli wynik jest, to koniec, a błąd należy do ścieżki odpowiedzi, nie do zapisu. Jeśli go nie ma, zachowaj możliwość, że aplikacja jeszcze go nie zatwierdziła: zadanie w kolejce, opóźniony widok odczytu albo opóźniona replika mogą przez jakiś czas ukrywać udany zapis.

Przed wyciągnięciem wniosku daj temu ustalone drugie spojrzenie i zapisz czas obu sprawdzeń. Dwa sprawdzenia w odstępie dwudziestu sekund to znacznie słabszy dowód niż dwa w odstępie dziesięciu minut.

Zdecyduj, czy drugie wysłanie jest bezpieczne

Odpowiedź zależy od operacji, nie od twojej cierpliwości. HTTP rozdziela metody, które można powtórzyć z tym samym zamierzonym skutkiem, od tych, których nie można, i odradza automatyczne powtórzenia drugiego rodzaju, chyba że wiadomo, że semantyka na to pozwala. Utworzenie komentarza, złożenie zamówienia i wysłanie płatności zwykle należą do drugiej grupy, dlatego drugie pozornie udane kliknięcie nic nie mówi o pierwszym.

Jeśli utrzymujesz klienta, użyj mechanizmu ponawiania lub idempotencji dokumentowanego przez API i powiąż go z tą samą operacją logiczną, zamiast generować nowy klucz dla każdej próby. Identyfikator żądania używany do śledzenia nie jest kluczem tłumienia duplikatów, chyba że serwer traktuje go jako taki.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

Klucz pomaga tylko wtedy, gdy usługa przechowuje go przy operacji i przy powtórzeniu zwraca pierwotny wynik. Sprawdź to zachowanie na punkcie końcowym środowiska testowego, zanim zaczniesz na nim polegać w produkcji.

Zbierz dowody, zanim znowu coś naciśniesz

Zachowaj wpis sieciowy, a nie zrzut ekranu błędu. Metoda żądania, URL, odpowiedź lub limit czasu i godzina zdarzenia to właśnie to, co administrator może skorelować z zapisami aplikacji. Eksportuj lub skopiuj wpis jako polecenie tylko wtedy, gdy następnie usuniesz z kopii pliki cookie, nagłówki autoryzacji i wszelkie prywatne treści. Zostaw własną sesję nietkniętą i nigdy nie odtwarzaj przechwyconego żądania z poświadczeniami jako skrótu.

Zapytaj właściciela usługi o jedno konkretne: czy operacja z tą treścią o tej godzinie się powiodła i czy istnieje do niej odwołanie? To pytanie ma odpowiedź, a "czy strona się zepsuła" nie ma.

Sens ćwiczenia polega na ustaleniu, że akcja zdarzyła się dokładnie raz. Komunikat o błędzie, który możesz zamknąć, to nie to samo co zapis, któremu możesz zaufać, a tego drugiego potrzebujesz, zanim wyślesz cokolwiek innego.

Powiązane artykuły