azure-sdk-for-net: Expose `RequestOptions` for HLC methods causing noisy logs/tracing

The upcoming Azure.RequestOptions gives us the chance to expose ErrorOptions from our convenience methods. We’re not planning to do this everywhere, but there have been a handful of cases where the noise of an expected exception degraded the observability/diagnosability experience for customers. This was discussed in detail in the ArchBoard meetings at https://github.com/Azure/azure-sdk/issues/3391. This work item tracks enabling the first set of experiences for HLC libraries.

Foundational

Use internally for both sync/async overloads:

Expose publicly both sync/async overloads:

Could either expose publicly or add an If(Not)Exists method to use internally for both sync/async overloads:

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 5
  • Comments: 20 (14 by maintainers)

Most upvoted comments

OMG, will someone please fix this 409 error in Table Storage… 10 years!!

#109

Yes @pakrym, this was meant to track everything blocked on RequestOptions, but I just split it into three lists to make it clearer which would expose RequestOptions, which would merely make use of it, and which we could do either way.

All of our sync/async APIs are required to have parity as validated by our analyzers, but I added a comment about it applying to both sync/async methods of all the affected APIs for good measure.

Hi @schafersm-fsa It looks like there is a bug here related to how we log in general. Tracking that here: https://github.com/Azure/azure-sdk-for-net/issues/33080

The Azure.Core and Generator work for this have been completed.