brak retry policy

Brak retry policy to usterka architektury pozbawionej zdefiniowanej zasady dotyczącej ponawiania nieudanych żądań.

Na czym polega brak retry policy

Retry policy, czyli polityka ponawiania, określa, co aplikacja ma zrobić po nieudanym żądaniu do innego komponentu. Może dotyczyć połączenia z serwerem HTTP, odczytu danych z usługi sieciowej, zapisu pliku w udziale sieciowym albo wywołania lokalnego procesu. Polityka powinna wskazywać, które błędy są uznawane za przejściowe, ile razy wolno ponowić operację, jaki odstęp zastosować między próbami oraz kiedy zakończyć działanie komunikatem o błędzie.

Brak retry policy nie oznacza wyłącznie braku jednej funkcji w kodzie. Jest to luka w projekcie obsługi błędów: aplikacja może natychmiast przerwać operację po chwilowej utracie sieci, ponawiać żądanie bez ograniczeń albo wykonywać kolejne próby w sposób zależny od przypadkowego zachowania biblioteki. W rezultacie ten sam problem może być raz widoczny jako szybki błąd, a innym razem jako długie zawieszenie programu, seria identycznych żądań lub niepełny zapis danych.

Jak nieudane żądanie przechodzi przez system

W typowym przepływie aplikacja przygotowuje żądanie, otwiera połączenie, oczekuje na odpowiedź i interpretuje wynik. Niepowodzenie może wystąpić na każdym z tych etapów. Przykładami są przekroczenie limitu czasu, chwilowa niedostępność hosta, reset połączenia, błąd DNS, odpowiedź HTTP 502 lub 503 oraz odrzucenie żądania z powodu przeciążenia. Każdy przypadek wymaga osobnej klasyfikacji, ponieważ ponowienie po błędzie sieciowym może mieć sens, lecz ponawianie żądania odrzuconego z powodu niepoprawnych danych zwykle tylko powtarza ten sam błąd.

Istotna jest także idempotencja operacji. Odczyt danych albo żądanie sprawdzające stan zazwyczaj można bezpieczniej powtórzyć niż operację tworzącą rekord, wysyłającą płatność lub uruchamiającą działanie uboczne. Jeżeli pierwsza próba została wykonana, ale odpowiedź zaginęła, druga próba może doprowadzić do podwójnego wykonania. Dlatego przy operacjach zmieniających stan stosuje się między innymi klucze idempotencji, identyfikatory żądań lub mechanizmy potwierdzające, czy poprzednia próba została przyjęta.

Elementy poprawnie zaprojektowanej polityki

Podstawą retry policy jest skończona liczba prób oraz limit całkowitego czasu oczekiwania. Odstępy między próbami często zwiększa się stopniowo, stosując exponential backoff, na przykład opóźnienie rosnące po każdej kolejnej próbie. Do opóźnienia dodaje się jitter, czyli niewielkie losowe odchylenie, aby wiele klientów nie wysłało ponownie żądań dokładnie w tej samej chwili. Bez takiego ograniczenia chwilowa awaria może zostać spotęgowana przez lawinę jednoczesnych ponowień.

Polityka powinna jasno rozróżniać błędy przejściowe od trwałych. Przekroczenie limitu czasu lub tymczasowa niedostępność usługi może uzasadniać ponowienie, natomiast błąd walidacji, brak uprawnień albo nieistniejący zasób zwykle wymaga korekty danych lub konfiguracji. W systemach, w których awaria utrzymuje się dłużej, przydatny jest circuit breaker. Po przekroczeniu ustalonego poziomu niepowodzeń czasowo zatrzymuje on kolejne wywołania i pozwala zależności odzyskać stabilność. Po czasie testowym można wykonać pojedynczą próbę kontrolną.

Rozpoznanie problemu podczas pracy na komputerze

Diagnostyka braku retry policy powinna obejmować logi klienta, czasy trwania żądań, kody odpowiedzi, liczbę prób oraz identyfikatory korelacyjne łączące zdarzenia po obu stronach połączenia. Warto sprawdzić, czy aplikacja loguje pierwszą próbę i każde ponowienie osobno, czy zapisuje powód decyzji oraz czy końcowy błąd nie ukrywa wcześniejszych przyczyn. Sam wpis „request failed” nie pozwala ustalić, czy problemem była sieć, limit czasu, odrzucenie przez usługę, czy brak mechanizmu ponawiania.

Na laptopie lub komputerze PC można również sprawdzić ustawienia aplikacji, konfigurację limitów czasu, dostępność połączenia sieciowego i powtarzalność problemu po ponownym uruchomieniu programu. Nie należy jednak traktować automatycznego retry jako uniwersalnego lekarstwa. Jeżeli przyczyną jest uszkodzona konfiguracja, błędne dane, niedziałający moduł sieciowy albo problem sprzętowy, kolejne próby tylko wydłużą oczekiwanie i mogą utrudnić analizę. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, gdy nieprawidłowe działanie oprogramowania wymaga sprawdzenia całego komputera.