Proxyfel i Spring WebClient: reaktiv hantering kontra loggning
Skilj mellan WebClients reaktiva felsignal, transportloggning och HTTP-statushantering vid ett proxyfel.
Transporten kan logga en misslyckad proxyanslutning medan applikationen också tar emot och hanterar det reaktiva felet. Själva loggposten bevisar inte att applikationens handler hoppades över.
Följ felsignalen i den kedja som faktiskt prenumereras på. En try/catch runt kod som bara bygger en Mono är ett annat omfång än hantering av ett senare nätverksfel.
| Operator | Effekt |
|---|---|
| doOnError | Utför en bieffekt medan felet fortsätter |
| onErrorMap | Omvandlar ett fel till ett annat fel |
| onErrorResume | Byter till en alternativ utgivare |
Välj det beteende som applikationen behöver. Att registrera ett mätvärde kräver inte att falskt lyckat innehåll returneras. Ett alternativt svar bör vara ett medvetet applikationsresultat, inte ett sätt att dölja en misslyckad rutt.
Skilj också mellan transportundantag och mottagna HTTP-felstatusar. En proxyanslutning kan misslyckas innan ett vanligt svar från målet finns, så en HTTP-statushanterare kan ha inget att granska. Bevara orsaken till en WebClientRequestException när det underliggande felet diagnostiseras.
Justera loggningen först efter att resultatet är förstått. Att stänga av hela transportloggaren kan ta bort bevis som behövs för en senare timeout, ett TLS-problem eller ett autentiseringsfel, utan att ändra det reaktiva pipelines beteende.