Return CorrelationId and OperationId when NoWait switch is used

[bgelens]

related issue #7145, #8846

Awesome NoWait is being implemented!

Please make sure that correlationId and operationId information is made part of the PSAzureOperationResponse. AFAICT it currently is not (unless RequestId is actually CorrelationId?) but it is crucial information to handle followup activities.

e.g. monitor based on operationId or have EventGrid subscription trigger some function that uses the CorrelationId provided by EventGrid for matching up the initial invocation.

This information is send as response header under the keys x-ms-correlation-request-id and x-ms-request-id.

[markcowl]

@bgelens There is also the x-ms-client-request-id which is often used for client-side correlation of responses / response traces.

In the case of AzureOperationResponse itself, the response headers are available in the object. Agreed that known headers used for corralting requests and retrieving logs should eb first class properties of the returned object in this case.

RequestId is populated from the x-ms-request-id header
OperationId is specific to a particular LRO pattern[AzureAsyncOperation] used by Compute and Network, the OperatioNId cna be used to call up logs for the operation.

BTW, -AsJob which runs LRO operatiosn on a background thread and returns immediately is already implemented acorss all cmdlets, NoWait is specifically for scenarios in which the user will specifically check the status of a request later and does not want a polling thresad.

[bgelens]

@markcowl Thanks for the additional information. I was not yet aware yet that OperationId is specific to Network and Compute.

We cannot use AsJob as we are running in Azure Functions and don't want to be blocked handling the next request or keep paying (as the function is monitoring) for something the platform (Azure) can do for us in another way (EventGrid). This is why I'm celebrating this NoWait effort!