Zatrzymaj pętlę rotacji proxy, zanim będzie działać wiecznie

Pula proxy może zamienić prostą awarię w zajętą pętlę. Wybierz adres, niepowodzenie, wybierz inny, znowu niepowodzenie. Jeśli każdy punkt końcowy jest nieosiągalny, bo twoja własna sieć nie działa, zmiana adresów nigdy nie naprawi przyczyny.

Daj operacji budżet, zanim wybierzesz pierwsze proxy z puli lub listy darmowych proxy: skończoną liczbę prób, ograniczone oczekiwanie na połączenie i odczyt oraz termin dla całego zadania. Limit czasu Requests kontroluje swoje udokumentowane zachowanie połączenia lub odczytu; sam nie ogranicza pętli, która wciąż wysyła nowe żądania.

Zdecyduj, co zasługuje na kolejną próbę

• Odrzucone połączenie przez proxy może uzasadniać wypróbowanie innego punktu końcowego.
• Odpowiedź celu wymaga własnej interpretacji. Otrzymanie błędu HTTP dowodzi, że jakaś ścieżka żądania została ukończona.
• Błąd uwierzytelniania proxy wymaga sprawdzenia punktu końcowego i konta, a nie walenia tymi samymi danymi przez rosnącą listę.

Zachowaj pierwotny wyjątek lub status razem z zapisem próby. Końcowy komunikat zawierający tylko „wszystkie proxy zawiodły” ukrywa, czy błędy miały w ogóle tę samą przyczynę.

Sprawdzanie stanu każdego proxy przed każdym rzeczywistym żądaniem dodaje kolejne żądanie i nadal nie gwarantuje, że następne się uda. Wykorzystaj ponownie świeże informacje o stanie tam, gdzie pasują do zadania, a potem pozwól rzeczywistej operacji zgłosić własny wynik.

Ponowna próba może powtórzyć pracę

Przy pobieraniu tylko do odczytu przejście na inne proxy jest zwykle prostsze niż ponowne odtworzenie wysyłki. Jeśli połączenie zerwie się po wysłaniu zakupu lub formularza, cel mógł już go przetworzyć. Przed ponownym odtworzeniem pracy stosuj mechanizm idempotencji usługi i zasady ponawiania HTTP.

Gdy budżet się wyczerpie, zwróć użyteczny błąd. Zadanie, które zatrzymuje się z dowodami, łatwiej naprawić niż takie, które po cichu kręci się dalej, aż ktoś to zauważy.