Deserialization policy consider 304 as an error leading to a telemetry exception being recorded

[Apokalypt]

• Package Name: core-client
• Package Version: 1.9.2
• Operating system: Windows 10 + Darwin 24.1
• nodejs
  • version: 18.20.4
• browser
  • name/version:
• typescript
  • version:
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://learn.microsoft.com

Describe the bug
The deserialization policy implemented in @azure/core-client considers any request with a status code not between 200 and 300 as an error which seems to be a good option. However, due to this behaviour each time an API answers 304 we are seing in Application Insights an exception which is not an expected behavior as a 304 is clearly expected

To Reproduce

1. Setup instrumentation with @azure/monitor-opentelemetry and register azure SDK instrumentation
2. Try to download a file from blob storage by providing the condition ifNoneMatch in order to receive 304
3. Look at

Expected behavior
HTTP calls with status code equals to 304 should not generate a telemetry exception

Screenshots

• Screenshot from Application insights showing the exception telemetry with the 304 status code
  
• Screenshot of the deserialization policy

Additional context
N/A

[xirzec]

My understanding is that 304 gets modeled as an error since the spec for downloadBlob only specifies responses for 200 and 206: https://github.com/Azure/azure-rest-api-specs/blob/b478dcdabacb37945ff89daa0eda1ae1afc98db4/specification/storage/data-plane/Microsoft.BlobStorage/stable/2025-01-05/blob.json#L2698

Since the default response is a StorageError for all unspecified status codes, the deserialization policy throws a RestError. Because the client doesn't handle this, it forwards the error to the consumer.

[xirzec]

Sorry, GitHub helpfully sent my response while I was in the middle of typing it. I don't think we can change the API contract for Storage methods that use conditional requests, but I am curious how AppInsights is hooking this, if it's on exceptions being created/thrown that's going to cause problems whenever exceptions are used for control flow

[JacksonWeber]

@xirzec @Apokalypt If a REST error is thrown and bubbles up to the top level of the application, I'd expect OpenTelemetry to create an exception record that we then export to Application Insights the same way as any unhandled exception. This seems like it'd be expected in the event of a "real" REST error. So apart for some special logic for 304s, I'm not sure if this would be considered "unexpected" behavior. Should be solvable by catching 304s on the client side for now, but strange to have that response code count as an "exception" at all.

[Apokalypt]

@JacksonWeber when you are talking about "client side" is it on Azure's SDK code or on my code when I use the library ?