Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Allow optional wrapping in NoFallbackAvailableException in CircuitBreaker

Abierto
  • ¿Algo no está bien?
#1,344 0 comentarios 8 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
java, spring
Área
backend

Línea de trabajo

Comienza con la clase CircuitBreaker en spring-cloud-commons/src/main/java/org/springframework/cloud/client/circuitbreaker/CircuitBreaker.java y revisa cómo el método run predeterminado envuelve las excepciones. Define cómo una propiedad de configuración opcional debe controlar ese comportamiento, asegurando que, cuando el envoltorio está deshabilitado, se conserve la excepción original y que, cuando está habilitado, se mantenga el comportamiento de NoFallbackAvailableException.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

waiting-for-triage

Is your feature request related to a problem? Please describe.
I'm building an application with Spring Cloud 2023 using Feign and Resilience4j.

In the CircuitBreaker class, methods that do not have a fallback by default have any exceptions thrown wrapped in a NoFallbackAvailableException:

default <T> T run(Supplier<T> toRun) {
  return run(toRun, throwable -> {
    throw new NoFallbackAvailableException("No fallback available.", throwable);
  });
}

This is not behaviour that we see with the vanilla implementation of Resilience4j, which just throws the exception as it is, without wrapping it.

I noticed this behaviour because I want to ignore an exception across all circuit breakers, and so set the following property resilience4j.circuitbreaker.configs.default.ignore-exceptions=.... With the automatic wrapping, however, higher-level code should be expecting a NoFallbackAvailableException instead of the exception that's actually been marked as ignored. Additionally, higher-level circuit breakers will not be able to continue ignoring this exception. [1]

Describe the solution you'd like
Would it be possible to make wrapping the exception in a NoFallbackAvailableException optional, controlled by some kind of property?

Describe alternatives you've considered
We can of course catch the NoFallbackAvailableException, get the root cause and then throw that exception.

[1] I know that multiple stacked circuit breakers aren't ideal, however I would like all Feign calls to be protected by circuit breakers, which can be done with the following property spring.cloud.openfeign.circuitbreaker.enabled=true. The downside of using this property is that you have no control over the fallbacks for those automatic circuit breakers. In this particular case, I am unable to add a fallback to the feign client itself, as it is shared among different services. Because of this, I would like to add a manual circuit breaker around the code using @CircuitBreaker(name = "getX", fallbackMethod = "getFallbackX").

Lenguaje dominante
Java
Estrellas
750
Forks
749
Merge medio
17 h 13 min
PR fusionados (30 d)
23

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de spring-cloud/spring-cloud-commons

Todos los issues de spring-cloud/spring-cloud-commons

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.