Azure-sdk-for-net: [FEATURE REQ] Add support for setting x-ms-client-request-id

[mjiderhamn]

Library or service name.
Azure.Storage.Blobs

Is your feature request related to a problem? Please describe.
Previous versions of the SDK allowed setting the x-ms-client-request-id request header, by providing a Microsoft.Azure.Storage.OperationContext instance with ClientRequestID set to the desired value.

Although the Generated/BlobRestClient.cs methods take a string requestId parameter, the Azure.Storage.Blobs.*Client classes provide no means of passing this parameter.

Please re-add this feature in the v12 SDK.

[jsquire]

//cc: @pakrym, @tg-msft

[pakrym]

What's your use-case for this feature?

[mjiderhamn]

@pakrym , the use-case at hand is that we parse storage analytics logs, do some processing and (depending on what has happened) update the metadata of blobs. We do not however want the updating of the metadata in itself to be considered an event that would cause processing and updating of metadata, as then we'd end up in a loop. Currently we're setting the x-ms-client-request-id to a known value, and ignore any analytics log entries with that value.

[pakrym]

Considering you don't need to have a per-client call request ids I encourage you to take a look at custom policy extension point: https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/core/Azure.Core/samples/Pipeline.md#implementing-a-syncronous-policy

You can easily implement a policy that sets a pre-defined value to a x-ms-client-request-id header for all outgoing requests from the client.

[mjiderhamn]

@pakrym , it seems pipeline policies would solve the problem at hand. Feel free to close this issue.

[tg-msft]

Let's keep this open to track adding better support in the client library.

//cc: @seanmcc-msft - this would be a great thing to add if we switch things to use more Options types

[mjiderhamn]

To anyone finding this issue looking for a workaround: the pipeline policy must not set the x-ms-client-request-id header directly, but instead set message.Request.ClientRequestId and let Azure.Core.Pipeline.ClientRequestIdPolicy (by default part of the pipeline) use it for setting the header. Then the request will also be properly signed.

[chinwobble]

@pakrym we also encountered this problem and would like to see this functionality added.

In our use case, the request-id needs to be dynamic.
See #10056