retry zbyt szybki (powielone dane)

Zbyt szybkie ponowienie próby może prowadzić do powielenia danych, gdy pierwotne żądanie faktycznie się powiodło.

Dlaczego zbyt szybki retry może powielić dane

Retry, czyli ponowienie żądania po błędzie, braku odpowiedzi albo przekroczeniu limitu czasu, nie zawsze oznacza, że pierwsza operacja się nie udała. Klient może przestać czekać, mimo że serwer odebrał żądanie, rozpoczął jego wykonywanie i ostatecznie zapisał wynik. Jeżeli w takiej sytuacji aplikacja natychmiast wysyła identyczne żądanie ponownie, serwer może potraktować je jako nową, niezależną operację. W efekcie ten sam zakup, wpis, zgłoszenie, wiadomość albo rekord zostanie utworzony więcej niż raz.

Problem wynika z rozdzielenia dwóch zdarzeń: zakończenia operacji po stronie serwera oraz otrzymania potwierdzenia przez klienta. Utrata pakietu, chwilowa niedostępność sieci, zamknięcie połączenia lub timeout mogą sprawić, że klient nie zna rzeczywistego rezultatu. Ponowienie próby usuwa niepewność komunikacyjną tylko pozornie, ponieważ druga wiadomość może zostać wykonana obok pierwszej. Sam fakt wystąpienia błędu transportowego nie dowodzi więc, że zapis nie nastąpił.

Różnica między ponowieniem a bezpieczną idempotencją

Bezpieczne retry wymaga określenia, czy dana operacja jest idempotentna. Operacja idempotentna daje ten sam efekt końcowy po wielokrotnym wykonaniu z tymi samymi parametrami. Odczyt danych zwykle można powtarzać bez tworzenia kolejnych rekordów, natomiast polecenie „utwórz nowy wpis” z definicji może za każdym razem wygenerować następny identyfikator. Nie należy zakładać, że każda metoda żądania HTTP albo każda funkcja biblioteki automatycznie chroni przed duplikacją.

Typowym zabezpieczeniem jest klucz idempotencji, czyli unikatowy identyfikator przypisany do jednej logicznej operacji. Klient wysyła ten sam klucz przy kolejnych próbach, a serwer zapisuje jego użycie i zwraca wcześniej ustalony rezultat zamiast wykonywać utworzenie ponownie. Klucz musi być związany z konkretną operacją, a nie generowany od nowa przy każdym retry. W przeciwnym razie serwer otrzyma kilka różnych identyfikatorów i nie będzie miał podstaw, aby rozpoznać powtórzenie.

Ochronę może uzupełniać unikatowe ograniczenie w bazie danych, warunek sprawdzający istnienie rekordu albo transakcja obejmująca zapis i rejestrację klucza. Takie mechanizmy muszą działać po stronie systemu wykonującego operację. Sam przycisk w interfejsie, ponowne kliknięcie lub lokalna kontrola czasu nie gwarantują, że dwa żądania nie dotrą do serwera ani że nie zostaną równolegle przetworzone.

Odstępy, timeouty i rozpoznawanie wyniku operacji

Zbyt szybkie retry zwiększa ryzyko przeciążenia i utrudnia odróżnienie awarii od opóźnienia. Jeżeli klient wysyła kolejne żądanie natychmiast po timeoutcie, pierwsza operacja może nadal być wykonywana. W systemach, w których zapis trwa dłużej niż oczekuje klient, kilka prób może nakładać się w czasie. Rozsądny mechanizm ponawiania stosuje rosnące odstępy, często określane jako backoff, oraz ogranicza liczbę prób. Przy wielu klientach przydatne jest także losowe rozproszenie czasu kolejnej próby, aby nie powodować jednoczesnego ponowienia po chwilowej awarii.

Odstęp czasowy nie rozwiązuje jednak sam problemu duplikacji. Opóźnienie zmniejsza prawdopodobieństwo kolizji, lecz nie odpowiada na pytanie, czy pierwsze żądanie zostało wykonane. Po timeoutcie aplikacja powinna, jeżeli protokół na to pozwala, sprawdzić stan operacji po identyfikatorze, odczytać utworzony rekord albo skorzystać z endpointu statusu. Jeżeli nie ma takiej możliwości, potrzebne są reguły obsługi niepewnego wyniku, na przykład komunikat informujący o konieczności weryfikacji zamiast bezwarunkowego tworzenia nowego wpisu.

Diagnostyka powinna porównywać identyfikatory żądań, znaczniki czasu, odpowiedzi serwera, wpisy w logach oraz rzeczywiste rekordy w systemie. Warto sprawdzić, czy aplikacja nie generuje nowego identyfikatora biznesowego przed każdą próbą, czy timeout jest krótszy od typowego czasu zapisu oraz czy ponowienie obejmuje operacje zapisu, a nie tylko błędy przejściowe. Istotne jest również rozróżnienie błędu połączenia od odpowiedzi aplikacji zawierającej jednoznaczny kod odrzucenia.

Jak ograniczyć skutki powielonych zapisów

Po wykryciu powielonych danych należy najpierw ustalić, które rekordy należą do tej samej operacji, opierając się na dostępnych identyfikatorach, czasie utworzenia i parametrach żądania. Usuwanie duplikatów bez sprawdzenia zależności może naruszyć powiązania między tabelami albo usunąć poprawny rekord zamiast kopii. Bezpieczniejsza jest korekta procedury zapisu: jeden klucz operacji powinien być rozpoznawany po stronie serwera, a kolejne próby powinny zwracać ten sam rezultat lub informację o stanie.

Na komputerze użytkownika objawem może być wielokrotne pojawienie się tego samego dokumentu, zadania, wiadomości albo wpisu po kliknięciu przycisku i dłuższym oczekiwaniu. Należy wtedy sprawdzić, czy problem występuje tylko przy niestabilnym połączeniu, po wznowieniu aplikacji lub po ręcznym ponownym kliknięciu. Pomocne są daty utworzenia, komunikaty o timeoutach i logi aplikacji. Nie należy wielokrotnie powtarzać operacji zapisu bez potwierdzenia jej stanu, zwłaszcza gdy system może wykonywać ją asynchronicznie.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z aplikacjami, połączeniem sieciowym oraz działaniem podzespołów, gdy nieprawidłowe retry jest jednym z objawów szerszej awarii systemu. Przy ocenie problemu warto przekazać opis kolejności działań, moment wystąpienia timeoutu i informację, czy dane zostały powielone po automatycznym, czy ręcznym ponowieniu próby.