Proxyfejl i Spring WebClient: reaktiv håndtering kontra logning
Skeln mellem WebClients reaktive fejlsignal, transportlogning og HTTP-statusbehandling under en proxyfejl.
Transporten kan logge en mislykket proxyforbindelse, mens applikationen også modtager og håndterer den reaktive fejl. Selve logposten beviser ikke, at applikationens handler blev sprunget over.
Følg fejlsignalet i den kæde, der faktisk abonneres på. Et try/catch omkring kode, der blot opretter en Mono, har et andet omfang end håndtering af en senere netværksfejl.
| Operator | Effekt |
|---|---|
| doOnError | Udfører en bivirkning, mens fejlen fortsætter |
| onErrorMap | Omdanner en fejl til en anden fejl |
| onErrorResume | Skifter til en alternativ udgiver |
Vælg den adfærd, applikationen har brug for. At registrere en metrik kræver ikke, at der returneres falsk vellykket indhold. Et alternativt svar bør være et bevidst applikationsresultat, ikke en måde at skjule en mislykket rute.
Skeln også mellem transportundtagelser og modtagne HTTP-fejlstatusser. En proxyforbindelse kan fejle, før der findes et almindeligt svar fra destinationen, så en HTTP-statusbehandler har muligvis intet at undersøge. Bevar årsagen til en WebClientRequestException, når den underliggende fejl diagnosticeres.
Justér først logningen, når resultatet er forstået. At slå hele transportloggeren fra kan fjerne beviser, der er nødvendige for en senere timeout, et TLS-problem eller en godkendelsesfejl, uden at ændre den reaktive pipelines adfærd.