Erori de proxy în Spring WebClient: tratare reactivă versus jurnalizare
Distingeți semnalul de eroare reactiv al WebClient, jurnalizarea transportului și tratarea stării HTTP în timpul unei defecțiuni a proxy-ului.
Transportul poate înregistra o conexiune proxy eșuată în timp ce aplicația primește și tratează și eroarea reactivă. Intrarea din jurnal singură nu demonstrează că handlerul aplicației a fost omis.
Urmați semnalul de eroare în lanțul care este efectiv abonat. Un try/catch în jurul codului care doar construiește un Mono este alt domeniu decât tratarea unei defecțiuni de rețea ulterioare.
| Operator | Efect |
|---|---|
| doOnError | Execută un efect secundar în timp ce eroarea continuă |
| onErrorMap | Transformă o eroare în altă eroare |
| onErrorResume | Comută la un editor alternativ |
Alegeți comportamentul de care are nevoie aplicația. Înregistrarea unei metrici nu impune returnarea unui conținut fals de succes. Un răspuns alternativ ar trebui să fie un rezultat deliberat al aplicației, nu o modalitate de a ascunde o rută eșuată.
Distingeți și excepțiile de transport de stările de eroare HTTP primite. O conexiune proxy poate eșua înainte să existe un răspuns obișnuit al destinației, așa că un handler de stare HTTP poate să nu aibă ce inspecta. Păstrați cauza unui WebClientRequestException atunci când diagnosticați defecțiunea de nivel inferior.
Ajustați jurnalizarea doar după ce înțelegeți rezultatul. Oprirea întregului logger de transport poate elimina dovezi necesare pentru un timeout, o problemă TLS sau o defecțiune de autentificare ulterioare, fără a schimba comportamentul pipeline-ului reactiv.