MVC Framework retry filter ignores retries and sleeps 1s between attempts when no backoff is configured

Abierto
  • ¿Algo no está bien?
#4,341 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java, spring, spring-boot
Área
api, backend

Línea de trabajo

Start with FrameworkRetryFilterFunctions.java, especially the CompositeRetryPolicy default backoff around lines 133–134, and compare it with shouldRetry() and the explicit backoff path. Read the RetryFilterFunctionBackoffTests style and reproduce the reported case with retries set to 5. Done means six attempts succeed with no delay when backoff is disabled; the issue author says a fix and test are already ready and plans to open a PR.

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

Descripción

waiting-for-triage

Describe the bug
Spring Cloud Gateway Server WebMVC 5.0.x (since 5.0.0, also on main), using the Spring Framework based retry filter (FrameworkRetryFilterFunctions, selected when Spring Retry is not on the classpath or use-framework-retry-filter=true).

When backoff is not configured, CompositeRetryPolicy falls back to RetryPolicy.withDefaults().getBackOff():

https://github.com/spring-cloud/spring-cloud-gateway/blob/b57ce6613e/spring-cloud-gateway-server-webmvc/src/main/java/org/springframework/cloud/gateway/server/mvc/filter/FrameworkRetryFilterFunctions.java#L133-L134

In Spring Framework 7 that is new FixedBackOff(1000, 3): a 1 second delay and at most 3 retries. RetryTemplate stops as soon as the BackOff returns STOP, so:

  • a retries value above 3 is silently capped at 3 (retry(c -> c.setRetries(5)) gives up after the 4th attempt with RetryException: Retry policy ... exhausted);
  • every retry blocks the servlet thread for 1 second, although the documentation lists the default as backoff: disabled.

The behaviour predates the backoff support (de023f51): before that commit CompositeRetryPolicy simply inherited the same default from RetryPolicy.getBackOff(). The attempt limit is already enforced by shouldRetry() (attemptCount >= config.getRetries()), and the explicit-backoff path uses an ExponentialBackOff with unlimited attempts, so the default can be a zero-delay FixedBackOff with unlimited attempts, leaving the count to shouldRetry().

Sample
Reproduced with Spring Boot 4.0.9 / Spring Cloud 2025.1.4: a route with retry(c -> c.setRetries(5)) in front of a backend that fails 5 times and then returns 200. The gateway made 4 attempts, answered 500 and took 3.07 s (Backing off for 1000ms three times, then RetryException). Expected: 6 attempts, 200, no delay.

A handler-based test in RetryFilterFunctionBackoffTests style shows the same thing. I have a fix with this test ready and will open a PR.

Lenguaje dominante
Java
Estrellas
4.9k
Forks
3.5k
Merge medio
2 d 4 h
PR fusionados (30 d)
9

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-gateway

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

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.