Errori proxy in Spring WebClient: gestione reattiva rispetto al logging
Distinguere il segnale di errore reattivo di WebClient, il logging del transport e la gestione dello stato HTTP durante un errore del proxy.
Il transport può registrare una connessione proxy non riuscita mentre l'applicazione riceve e gestisce anche l'errore reattivo. La sola voce di log non dimostra che l'handler dell'applicazione sia stato saltato.
Seguire il segnale di errore nella catena che viene effettivamente sottoscritta. Un try/catch attorno a codice che si limita a costruire un Mono è un ambito diverso dalla gestione di un guasto di rete successivo.
| Operatore | Effetto |
|---|---|
| doOnError | Esegue un effetto collaterale mentre l'errore continua |
| onErrorMap | Trasforma un errore in un altro errore |
| onErrorResume | Passa a un publisher alternativo |
Scegliere il comportamento necessario all'applicazione. Registrare una metrica non richiede di restituire contenuti di successo fittizi. Una risposta alternativa deve essere un risultato deliberato dell'applicazione, non un modo per nascondere una rotta non riuscita.
Distinguere anche le eccezioni del transport dagli stati di errore HTTP ricevuti. Una connessione proxy può fallire prima che esista una normale risposta della destinazione, quindi un handler di stato HTTP può non avere nulla da esaminare. Conservare la causa di una WebClientRequestException durante la diagnosi del guasto di livello inferiore.
Regolare il logging solo dopo aver compreso l'esito. Disattivare l'intero logger del transport può rimuovere prove necessarie per un timeout, un problema TLS o un errore di autenticazione successivi, senza modificare il comportamento della pipeline reattiva.