You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, during initialization of the SDK we populate the operation id to a random value.
However, there are some customers that are looking to join the initial server side request (the one that returns the page) with the requests that are sent from the browser.
This is especially important as part of auto attach options when the customer will want to join the requests.
The customer expects to see the same operation_Id values for the requests (server-side) and pageView (client-side) telemetries when visiting a URL in their application. This behavior is described in the official documentation here:
Currently, during initialization of the SDK we populate the operation id to a random value.
However, there are some customers that are looking to join the initial server side request (the one that returns the page) with the requests that are sent from the browser.
This is especially important as part of auto attach options when the customer will want to join the requests.
The customer expects to see the same operation_Id values for the requests (server-side) and pageView (client-side) telemetries when visiting a URL in their application. This behavior is described in the official documentation here:
https://docs.microsoft.com/en-us/azure/azure-monitor/app/correlation#example
In the doc's example, for a single page visit the request has an operation_Id of STYz and the pageView also has an operation_Id of STYz.
The text was updated successfully, but these errors were encountered: