[Feature Request] Consider allowing the ability to opt-out of distributed tracing for expected HTTP error responses

Summary

In some situations, service calls return an HTTP response code in the range normally interpreted as an exception though that response is an expected and normal scenario to the consumer of the associated client library. For example, when using an If-Match constraint with the Storage client library when updating metadata for a blob, a mismatch in the ETag results in an HTTP 412 (Precondition Failed) response.

While this status code is semantically correct, it is also considered an expected and normal scenario to some callers. For example, the Event Processor client library will attempt to claim ownership of a partition by making a conditional request. Since multiple processor instances are competing for ownership, it is expected that the conditional request will not succeed for the majority of them. In this case, the Event Hubs client handles the resulting storage exception and considers it as part of the normal application path.

However, within the Storage client, the diagnostics scope considers the request a failure an emits the associated exception data. When customers using the Event Hubs processor are integrating with Application Insights, they are seeing diagnostics information that indicates errors in their application, though these entries are not indicating actual problems and are just noise.

It may be worth considering if we wanted to include a feature that would allow consumers of a client library to declare expected response failures as such and avoid emitting error diagnostics for them.

Related Items

• [BUG] Event Hub Processor Host - creating errors when checkpointing to blob (#9908)

[Archomeda]

Is there any progress on this? Seeing that this issue has existed for 2 years makes me kinda sad.

I hook into the ILogger for some custom log targets, and I get this noise as well which is incredibly annoying.

[annelo-msft]

Hi @Archomeda - you’re correct that this is only implemented in Azure.Data.Tables currently. As I understand it, this issue tracks the work to incorporate the feature in the Storage libraries. @seanmcc-msft is driving that work. My understanding of the process is that the client feature crew will work with architects to determine how to expose this functionality on those libraries. They do have the option to expose the RequestContext directly to give callers full control of the pipeline on a per-request basis.