[BUG] [azure-identity] ClientSecretCredential.getTokenSync logs InterruptedException at ERROR — surfaces reactive cancellation as log spam

[o-shevchenko]

Library name

azure-identity

Library version

1.18.3 (also reproduces on the latest releases I checked — code path unchanged)

Describe the bug

ClientSecretCredential.getTokenSync (and IdentitySyncClient.authenticateWithConfidentialClient it delegates to) unconditionally logs InterruptedException at ERROR level even though InterruptedException is a cooperative cancellation signal, not an actual authentication failure.

In a Spring Boot Reactor / Microsoft Graph application running under Kubernetes, this surfaces as a flood of:

Azure Identity => ERROR in getToken() call for scopes [https://graph.microsoft.com/.default]: java.lang.InterruptedException

during pod scale-down and any other moment when an upstream Reactor subscription is cancelled while the caller thread is mid-call to getTokenSync.

Root cause (from a source trace)

In sdk/identity/azure-identity/src/main/java/com/azure/identity/implementation/IdentitySyncClient.java (~line 135):

public AccessToken authenticateWithConfidentialClient(TokenRequestContext request) {
    // ...
    try {
        return new MsalToken(confidentialClient.acquireToken(builder.build()).get());
    } catch (InterruptedException | ExecutionException e) {
        throw LOGGER.logExceptionAsError(new RuntimeException(e));  // ← logs at ERROR
    }
}

CompletableFuture.get() runs on the caller's thread. If the caller's interrupt flag is set while .get() is blocking — which is exactly what reactor.core.scheduler.BoundedElasticScheduler.Worker.dispose() does when an upstream subscription is cancelled — Future.get() throws InterruptedException immediately, even though MSAL has done nothing wrong.

That exception is then caught at ClientSecretCredential.getTokenSync (~line 137):

} catch (Exception e) {
    LoggingUtil.logTokenError(LOGGER, identityClient.getIdentityClientOptions(), request, e);
    throw e;
}

and logged unconditionally at ERROR via LoggingUtil.logTokenError.

Microsoft Graph SDK reaches this path through microsoft-kiota-authentication-azure's AzureIdentityAccessTokenProvider.getAuthorizationToken at creds.getTokenSync(context).getToken(), which is called synchronously from the request pipeline. So any Reactor cancellation upstream of a Graph call manifests as ERROR-level log noise on the caller thread.

Why this matters

• Operational dashboards light up during normal pod scale-down — the "errors" aren't real failures; the request will retry on another replica.
• InterruptedException is the JVM's standard cooperative-cancellation signal. By every Java convention, it shouldn't be treated as ERROR.
• Downstream wrappers can't suppress the log: it fires inside the SDK's own try/catch before any caller can intercept.

Reproducer (self-contained, ~0.5s)

import ch.qos.logback.classic.*;
import ch.qos.logback.core.read.ListAppender;
import ch.qos.logback.classic.spi.ILoggingEvent;
import com.azure.core.credential.TokenRequestContext;
import com.azure.identity.ClientSecretCredentialBuilder;
import com.sun.net.httpserver.HttpServer;
import java.net.InetSocketAddress;
import java.util.concurrent.atomic.AtomicBoolean;
import org.slf4j.LoggerFactory;

public class Repro {
    public static void main(String[] args) throws Exception {
        HttpServer slow = HttpServer.create(new InetSocketAddress("127.0.0.1", 0), 0);
        slow.createContext("/", ex -> {
            try { Thread.sleep(2000); } catch (InterruptedException ignored) {}
            ex.sendResponseHeaders(404, -1); ex.close();
        });
        slow.start();

        var appender = new ListAppender<ILoggingEvent>();
        appender.start();
        var sdkLogger = (Logger) LoggerFactory.getLogger("com.azure.identity.ClientSecretCredential");
        sdkLogger.addAppender(appender);
        sdkLogger.setLevel(Level.ERROR);

        var credential = new ClientSecretCredentialBuilder()
            .tenantId("11111111-1111-1111-1111-111111111111")
            .clientId("22222222-2222-2222-2222-222222222222")
            .clientSecret("not-a-real-secret")
            .authorityHost("https://127.0.0.1:" + slow.getAddress().getPort() + "/")
            .build();

        Thread target = Thread.currentThread();
        AtomicBoolean stop = new AtomicBoolean();
        Thread interrupter = new Thread(() -> {
            // Mimic BoundedElasticScheduler.Worker.dispose() interrupting a cancelled worker
            while (!stop.get()) {
                target.interrupt();
                try { Thread.sleep(20); } catch (InterruptedException ignored) {}
            }
        });
        interrupter.setDaemon(true);
        interrupter.start();

        try {
            credential.getTokenSync(new TokenRequestContext()
                .addScopes("https://graph.microsoft.com/.default"));
        } catch (Throwable ignored) {}
        stop.set(true);
        Thread.interrupted();
        interrupter.join();
        slow.stop(0);

        appender.list.stream()
            .filter(e -> e.getLevel() == Level.ERROR)
            .forEach(e -> System.out.println(e.getFormattedMessage()));
    }
}

Output:

Azure Identity => ERROR in getToken() call for scopes [https://graph.microsoft.com/.default]: java.lang.InterruptedException

(Note: a single interrupt is absorbed by getTokenSync's cache path silent catch (Exception e) {}, so the reproducer keeps interrupting to land on the non-cache .get() too. Production conditions match: schedulers typically re-interrupt cancelled workers during disposal.)

Expected behavior

InterruptedException (and any cause containing it) should not be logged at ERROR — it's not an error. Options I'd find acceptable, in rough order of preference:

1. Special-case it: skip the LoggingUtil.logTokenError call when the cause is InterruptedException; just rethrow. Caller can still observe the exception.

} catch (Exception e) {
    if (!hasCause(e, InterruptedException.class)) {
        LoggingUtil.logTokenError(LOGGER, identityClient.getIdentityClientOptions(), request, e);
    }
    throw e;
}

2. Demote to DEBUG: log InterruptedException cases at DEBUG instead of ERROR.

3. Add a configuration knob so consumers can suppress the log.

Either way, preserving the interrupt flag (Thread.currentThread().interrupt()) before rethrowing would also be friendlier to downstream code.

Workaround

Wrap the credential, override getTokenSync to route through the async path (getToken().block()), and catch InterruptedException before it reaches the SDK's logging path. Documented locally at datarobot/browser-sharepoint#302 with a reproducer test at datarobot/browser-sharepoint#301.

Happy to open a PR with the upstream fix if the maintainers indicate which of the options above is preferred.

Setup (pom.xml/build.gradle and Java version used)

implementation("com.azure:azure-identity:1.18.3")
implementation("com.azure:azure-core:1.58.0")
implementation("com.azure:azure-core-http-okhttp:1.13.4")
implementation("com.microsoft.graph:microsoft-graph:6.64.0")  // optional, sync path also reached directly

Java 17/21 — behaviour is the same because the bug is in the sync API contract, not the JDK version.

[github-actions]

@g2vinay @joshfree

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[o-shevchenko]

We've since hit a second failure mode that produces the same Azure Identity => ERROR in getToken() ... log line at ERROR but with a different exception suffix:

Azure Identity => ERROR in getToken() call for scopes [https://graph.microsoft.com/.default]: Shutdown in progress

Trigger:

• Pod receives SIGTERM, JVM enters shutdown phase
• azure-core SharedExecutorService's own JVM shutdown hook fires and shuts down its executor
• An in-flight request still drains through gRPC/Spring; the request needs a token and reaches ClientSecretCredential.getToken
• Inside MSAL/azure-core, something calls SharedExecutorService.schedule(...), which delegates to ensureNotShutdown() (azure-core SharedExecutorService.java:362):

  private ScheduledExecutorService ensureNotShutdown() {
      return EXECUTOR_UPDATER.updateAndGet(INSTANCE,
          ex -> (ex == null || ex.isShutdown() || ex.isTerminated()) ? createSharedExecutor() : ex);
  }

• The current executor is shutdown, so createSharedExecutor() runs — which calls CoreUtils.addShutdownHookSafely(shutdownThread) (SharedExecutorService.java:388)
• ImplUtils.addShutdownHookSafely (ImplUtils.java:525) calls Runtime.getRuntime().addShutdownHook(shutdownThread) without catching IllegalStateException
• JVM is mid-shutdown → Runtime.addShutdownHook throws IllegalStateException("Shutdown in progress")
• That exception propagates through MSAL → SDK's async chain → doOnError(LoggingUtil::logTokenError) → log at ERROR

So in addition to the InterruptedException case in the original report, this is another "shutdown signal logged as ERROR" anti-pattern. Both reach the user via the same LoggingUtil.logTokenError sink.

Suggested fix (extends original options):

The "don't log shutdown signals at ERROR" rule should cover both:

private static boolean isShutdownSignal(Throwable t) {
    for (Throwable cur = t; cur != null; cur = cur.getCause()) {
        if (cur instanceof InterruptedException) return true;
        if (cur instanceof IllegalStateException
                && "Shutdown in progress".equals(cur.getMessage())) return true;
    }
    return false;
}

…and skip LoggingUtil.logTokenError (or demote to DEBUG) when isShutdownSignal(e) returns true. Both in the sync getTokenSync catch block and the async doOnError.

Also worth considering: making ImplUtils.addShutdownHookSafely actually safe — i.e., catch and swallow IllegalStateException when the JVM is already shutting down (there's no point adding a hook then; the hook would never run anyway). Same for SharedExecutorService.ensureNotShutdown() — when called from a thread that's inside JVM shutdown, returning the already-shutdown executor (instead of trying to make a new one) would let callers see a clean rejected-execution failure rather than a misleading log.

Local workaround for both cases is documented at datarobot/browser-sharepoint#302 (short-circuit at Kiota's AuthenticationProvider after ContextClosedEvent).

[o-shevchenko]

Quick update on the local workaround — after iteration we landed on a different (smaller, cleaner) approach than the original AuthenticationProvider short-circuit I mentioned:

1. Inject a Spring-managed ExecutorService into ClientSecretCredentialBuilder.executorService(...) (with destroyMethod = "shutdown"). This pushes MSAL token work off the global SharedExecutorService. Because Spring's bean destruction drains our executor during context close — before the JVM enters its shutdown phase — SharedExecutorService.ensureNotShutdown() never sees its singleton as shut down, never re-creates it, never calls addShutdownHook. The "Shutdown in progress" path is eliminated at the source.

2. Wrap the credential so getTokenSync routes through getToken().toFuture().get() with future.cancel(true) on InterruptedException. Cancellation isn't an error signal in Reactor, so the SDK's doOnError(LoggingUtil::logTokenError) never fires. Translates interruption to a clean ServiceUnavailableException.

Final shape at datarobot/browser-sharepoint#302 — confirmed silent under continuous mid-call interrupts and pod scale-down in staging.

Both pieces become unnecessary once the SDK stops treating shutdown signals (InterruptedException, IllegalStateException("Shutdown in progress")) as ERROR — happy to send an upstream PR if the maintainers indicate which option (skip-the-log, demote-to-DEBUG, configuration knob) is preferred.