[BUG] RequestRetryOptions tryTimeout has no effect on synchronous Storage clients

Abierto
  • ¿Algo no está bien?
#51,144 2 comentarios 1 reacción 2 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@browndav-msft ya está trabajando en esto.

Desde el 6/11/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Client customer-reported needs-team-attention question Service Attention Storage

Describe the bug
For synchronous Storage clients (for example BlobServiceClient), the per-try timeout configured with RequestRetryOptions (tryTimeout) never fires. A stalled request runs until the HTTP client's own timeout (60 s by default for Netty) instead of the configured try timeout. The async client with the same options times out as expected.

Root cause
RequestRetryPolicy.attemptSync runs each try as:

Mono<HttpResponse> httpResponseMono = Mono.fromCallable(() -> next.clone().processSync());
httpResponseMono = httpResponseMono.timeout(this.requestRetryOptions.getTryTimeoutDuration());
HttpResponse response = httpResponseMono.block();

Mono.fromCallable runs the blocking processSync() on the subscribing thread inside request(n). In FluxTimeout.TimeoutMainSubscriber.onSubscribe, actual.onSubscribe(this) (which triggers request(n) and therefore the whole blocking call) runs before firstTimeout.subscribe(timeoutSubscriber) arms the timer. By the time the timer is armed, the value has already been emitted, so the timeout can never fire. attemptAsync is not affected because process() does not block on subscribe.

Stack of a sync call blocked on a stalled server (trimmed):

reactor.core.publisher.Mono.block(Mono.java:1779)
com.azure.core.http.netty.NettyAsyncHttpClient.sendSync(NettyAsyncHttpClient.java:194)
...
com.azure.storage.common.policy.RequestRetryPolicy.lambda$attemptSync$0(RequestRetryPolicy.java:266)
reactor.core.publisher.MonoCallable$MonoCallableSubscription.request(MonoCallable.java:137)
reactor.core.publisher.Operators$MultiSubscriptionSubscriber.request(Operators.java:2330)
reactor.core.publisher.SerializedSubscriber.request(SerializedSubscriber.java:151)

To Reproduce
Point a client at a server that accepts the TCP connection but never responds (a ServerSocket that is never accept()ed is enough), with maxTries = 1 and tryTimeout = 1s.

Code Snippet

import com.azure.storage.blob.BlobServiceClientBuilder;
import com.azure.storage.common.StorageSharedKeyCredential;
import com.azure.storage.common.policy.RequestRetryOptions;
import com.azure.storage.common.policy.RetryPolicyType;
import java.net.ServerSocket;
import java.time.OffsetDateTime;

public class TryTimeoutRepro {
  public static void main(String[] args) throws Exception {
    // The listen backlog completes the TCP handshake, but nothing is ever written back.
    try (ServerSocket stalled = new ServerSocket(0)) {
      BlobServiceClientBuilder builder = new BlobServiceClientBuilder()
          .endpoint("http://127.0.0.1:" + stalled.getLocalPort() + "/devstoreaccount1")
          .credential(new StorageSharedKeyCredential("devstoreaccount1",
              "Eby8vdM02xNOcqCfGfP/mkP3+rZTt5tF5If1fMvj08QzZLOiT4E5lZaz0smU4wFwbIsrpPoIQx=="))
          .retryOptions(new RequestRetryOptions(RetryPolicyType.EXPONENTIAL,
              1 /* maxTries */, 1 /* tryTimeoutInSeconds */, null, null, null));
      OffsetDateTime start = OffsetDateTime.now();

      long t0 = System.nanoTime();
      try {
        builder.buildAsyncClient().getUserDelegationKey(start, start.plusHours(1)).block();
      } catch (RuntimeException e) {
        System.out.println("async: " + e.getCause() + " after " + ms(t0) + " ms");
      }

      t0 = System.nanoTime();
      try {
        builder.buildClient().getUserDelegationKey(start, start.plusHours(1));
      } catch (RuntimeException e) {
        System.out.println("sync: " + e + " after " + ms(t0) + " ms");
      }
    }
  }

  private static long ms(long t0) {
    return (System.nanoTime() - t0) / 1_000_000;
  }
}

Observed with an equivalent test:

  • async: TimeoutException after ~1009 ms
  • sync: still running after 5000 ms; each try only ends at the HTTP client's 60 s response timeout (two tries took ~120 s)

The same behavior in plain Reactor:

Mono.fromCallable(() -> { Thread.sleep(4000); return "OK"; })
    .timeout(Duration.ofSeconds(1))
    .block();                                   // returns "OK" after ~4001 ms, no timeout

Mono.fromCallable(() -> { Thread.sleep(4000); return "OK"; })
    .subscribeOn(Schedulers.boundedElastic())
    .timeout(Duration.ofSeconds(1))
    .block();                                   // TimeoutException after ~1003 ms

Expected behavior
Each sync try fails with a timeout after tryTimeout and is retried, the same as on the async client.

Possible fix
Run the blocking call off the subscribing thread (for example subscribeOn(Schedulers.boundedElastic())), or enforce the timeout with an executor and Future.get(timeout). If changing this is not desirable, documenting that tryTimeout does not apply to sync clients would help.

Workaround
Set connect, response and read timeouts on the HTTP client (NettyAsyncHttpClientBuilder) and pass it with .httpClient(...), or use the async client.

Setup

  • OS: Ubuntu 20.04 (x86_64)
  • Library/Libraries: azure-storage-blob 12.36.0, azure-storage-common 12.35.0, azure-core 1.60.0, azure-core-http-netty 1.16.8, reactor-core 3.7.19, reactor-netty-http 1.2.18. The code in RequestRetryPolicy.attemptSync is unchanged on main.
  • Java version: 25 (GraalVM 25.0.4)
  • Frameworks: none

Information Checklist

  • Bug Description Added
  • Repro Steps Added
  • Setup information Added
Lenguaje dominante
Java
Estrellas
2.6k
Forks
2.2k
Merge medio
2 d 2 h
PR fusionados (30 d)
257

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 Azure/azure-sdk-for-java

Todos los issues de Azure/azure-sdk-for-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.