Błędy proxy w Spring WebClient: obsługa reaktywna a logowanie
Rozróżnij reaktywny sygnał błędu WebClienta, logowanie transportu i obsługę statusu HTTP podczas awarii proxy.
Transport może zapisać w logu nieudane połączenie proxy, podczas gdy aplikacja również odbiera i obsługuje błąd reaktywny. Sam wpis w logu nie dowodzi, że pominięto procedurę obsługi aplikacji.
Śledź sygnał błędu w łańcuchu, który jest faktycznie subskrybowany. try/catch wokół kodu, który jedynie buduje Mono, to inny zakres niż obsługa późniejszej awarii sieci.
| Operator | Efekt |
|---|---|
| doOnError | Wykonuje efekt uboczny, gdy błąd trwa |
| onErrorMap | Przekształca błąd w inny błąd |
| onErrorResume | Przełącza na alternatywnego wydawcę |
Wybierz zachowanie, którego potrzebuje aplikacja. Zapisanie metryki nie wymaga zwracania fałszywej treści sukcesu. Odpowiedź alternatywna powinna być zamierzonym wynikiem aplikacji, a nie sposobem ukrycia nieudanej trasy.
Rozróżniaj też wyjątki transportu od odebranych statusów błędu HTTP. Połączenie proxy może zawieść, zanim istnieje zwykła odpowiedź miejsca docelowego, więc procedura obsługi statusu HTTP może nie mieć czego sprawdzić. Zachowaj przyczynę WebClientRequestException podczas diagnozowania awarii niższego poziomu.
Dostosuj logowanie dopiero po zrozumieniu wyniku. Wyłączenie całego loggera transportu może usunąć dowody potrzebne do późniejszego przekroczenia limitu czasu, problemu TLS lub błędu uwierzytelniania, bez zmiany zachowania potoku reaktywnego.