[Nilesh Choudhary (4gust)]

What's going on

Fixes #634.

Managed identity token acquisitions were intermittently failing with context canceled right after a successful HTTP 200, especially when the identity endpoint (IMDS/App Service) was responding slowly. That is exactly when the retry loop kicks in, so the bug showed up precisely in the situation the retry logic is supposed to handle.

The root cause

Inside retry() in apps/managedidentity/managedidentity.go, each attempt created a per-attempt context with defer tryCancel() inside the loop. Because defer runs when the function returns (not at the end of each iteration), every stacked cancel fired the moment retry() returned, including the one tied to the response body that was being handed back to the caller.

The caller then did io.ReadAll(resp.Body) on a body whose context had already been canceled. Whether that read succeeded was a race against the transport having buffered the body. Small token JSON over a fast connection usually won the race, which is why this was intermittent and got much worse when the endpoint was slow.

The fix

• Buffer the response body into memory (small in-memory reader) while the attempt's context is still alive, on both the success path and the final-attempt path, then cancel. Once the body is buffered, canceling the context can no longer break the caller's read.
• Manage the per-attempt cancels explicitly instead of stacking defer calls in the loop. The previous attempt's context is canceled only after its body has been drained, so connections can still be reused. This also clears up the classic "defer inside a loop" resource retention that was called out in the issue.

Tests

• Added TestRetrySlowBodyDoesNotCancelContext, a regression test using a real httptest server that returns a retryable 500 first and then a slow body. It fails on the old code with context canceled and passes with the fix.
• Added TestRetryPolicyDisabledSlowBody to confirm the single-request (retry disabled) path handles the same slow body, isolating the bug to retry().
• Verified the existing TestRetryFunction and Test_RetryPolicy_For_AcquireToken still pass, including the "max retries reached" case that reads the body of a retryable response.
• Cross-referenced against the exact repro from the issue (run as an external module against this branch): it reproduces context canceled on the pre-fix code and passes after the fix.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud