Errores de proxy en Spring WebClient: manejo reactivo frente a registro
Distinga la señal de error reactiva de WebClient, el registro del transporte y el manejo del estado HTTP durante un fallo del proxy.
El transporte puede registrar una conexión de proxy fallida mientras la aplicación también recibe y maneja el error reactivo. La entrada del registro por sí sola no demuestra que se haya omitido el manejador de la aplicación.
Siga la señal de error en la cadena que realmente se suscribe. Un try/catch alrededor de código que solo construye un Mono es un ámbito distinto del manejo de un fallo de red posterior.
| Operador | Efecto |
|---|---|
| doOnError | Ejecuta un efecto secundario mientras el error continúa |
| onErrorMap | Transforma un error en otro error |
| onErrorResume | Cambia a un publicador alternativo |
Elija el comportamiento que necesita la aplicación. Registrar una métrica no exige devolver contenido de éxito falso. Una respuesta alternativa debe ser un resultado deliberado de la aplicación, no una forma de ocultar una ruta fallida.
Distinga también las excepciones de transporte de los estados de error HTTP recibidos. Una conexión de proxy puede fallar antes de que exista una respuesta ordinaria del destino, así que un manejador de estado HTTP puede no tener nada que inspeccionar. Conserve la causa de una WebClientRequestException al diagnosticar el fallo de nivel inferior.
Ajuste el registro solo después de comprender el resultado. Desactivar todo el logger de transporte puede eliminar pruebas necesarias para un tiempo de espera, un problema TLS o un fallo de autenticación posteriores, sin cambiar el comportamiento de la canalización reactiva.