Mga error ng proxy sa Spring WebClient: reaktibong paghawak kumpara sa pag-log
Ihiwalay ang reaktibong signal ng error ng WebClient, pag-log ng transport, at paghawak ng HTTP status kapag nabigo ang proxy.
Maaaring i-log ng transport ang nabigong koneksyon ng proxy habang tinatanggap at hinahawakan din ng application ang reaktibong error. Ang log entry lamang ay hindi nagpapatunay na nilaktawan ang handler ng application.
Sundan ang signal ng error sa chain na aktwal na sinusubscribehan. Ang try/catch sa paligid ng code na gumagawa lamang ng Mono ay ibang saklaw kaysa sa paghawak ng mas huling pagkabigo ng network.
| Operator | Epekto |
|---|---|
| doOnError | Nagsasagawa ng side effect habang nagpapatuloy ang error |
| onErrorMap | Binabago ang isang error tungo sa ibang error |
| onErrorResume | Lumilipat sa alternatibong publisher |
Piliin ang pag-uugali na kailangan ng application. Ang pagtatala ng metric ay hindi nangangailangan ng pagbabalik ng pekeng matagumpay na nilalaman. Ang alternatibong tugon ay dapat maging sinadyang resulta ng application, hindi paraan upang itago ang nabigong ruta.
Ihiwalay din ang mga exception ng transport sa mga natanggap na HTTP error status. Maaaring mabigo ang koneksyon ng proxy bago pa umiral ang ordinaryong tugon ng destinasyon, kaya maaaring walang masuri ang handler ng HTTP status. Panatilihin ang dahilan ng WebClientRequestException kapag sinusuri ang mas mababang antas ng pagkabigo.
Isasaayos ang pag-log pagkatapos lamang maunawaan ang resulta. Ang pagpatay sa buong logger ng transport ay maaaring mag-alis ng ebidensiyang kailangan para sa mas huling timeout, problema sa TLS, o pagkabigo ng authentication, nang hindi binabago ang pag-uugali ng reaktibong pipeline.