BlobNotFound Exception with 200/204 response code

[siyad-dt]

BlobNotFound Exception with 200/204 response code

When the consumer uses the SDK to update or delete an existing blob, we receive a 200 response code; however, the trace reveals a BlobNotFound exception.
Apart from this, there is no other relevant information about the issue in the trace.

Exception

<?xml version="1.0" encoding="utf-8"?>
<Error><Code>BlobNotFound</Code><Message>The specified blob does not exist.
RequestId:1dd5f144-f01e-0080-6c7f-5a9cf71e41b7
Time:2025-11-21T00:40:43.9242278Z</Message></Error>

To Reproduce
This is not reproducible from our end. It's happening to us in production, though.
Whenever this occurs, we see the com.microsoft.aad.msal4j.MsalClientException with a `token not found in the cache' error.

Code Snippet
Add the code snippet that causes the issue.

Expected behavior
When the response code is 200, we don't want to see this exception. This is creating false positives in our exception monitors.

Setup (please complete the following information):

• OS: macOS
• IDE: IntelliJ
• Java version: 21
• App Server/Environment: Netty

Information Checklist

• Bug Description Added
• Repro Steps Added
• Setup information Added

[samvaity]

@ibrandes Could you take a look at the above reported bug and help out, thanks!

[ibrandes]

@siyad-dt

Please provide a code sample to help us investigate this issue.

[github-actions]

Hi @siyad-dt. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[siyad-dt]

Hello @ibrandes, I am not sure how this will help. The exception in this situation originates from the SDK.
From our side,
We use the standard update and delete API's which works as expected almost all the time.
Sometimes we get the blob not found error when there is no file that exists, and it is a valid one.
But we get the same exception from the same API, and the response is 200, and the operation succeeds, yet we discover this exception in the trace.
This is not a reproducible error on our end, but we occasionally observe it in production, as shown in the image.
Is there any additional information we can provide to assist you in debugging this?