Access the correlation context information to send operation ID in response

[Apokalypt]

Context

My team and I are trying to improve the way we work with logs so that we can be more efficient when we encounter bugs in our APIs. To do this, we'd like to expose the operation ID and the ID of the parent operation in the body of the response we send.

Feature request

In order to do this, we need to be able to retrieve this information. We thought of a simple solution: expose the correlation context in the request object ( request.__context ) so that we can retrieve the operation ID / parent ID and expose it in the API response in the event of an error.

If it's already possible to do this, we'd love to hear about it. If not, do you think it would be feasible and interesting?

[hectorhdzg]

@Apokalypt telemetry processors should have the request object and also correlation context available for you to consume, more info here.

[Apokalypt]

@Apokalypt telemetry processors should have the request object and also correlation context available for you to consume, more info here.

I'm not sure to understand how to proceed. We've already used these methods to filter some data, but I can't see how this would allow us to access the correlation ID in our error handler (using express) and return it in the API response.

[hectorhdzg]

Well depends on when do you need the information, we should also be adding headers with correlation context information, have you tried reading the response headers?

[Apokalypt]

Well depends on when do you need the information, we should also be adding headers with correlation context information, have you tried reading the response headers?

To be more explicit, here is a small code that show what we would like to do :

const appInsights = require("applicationinsights");
appInsights.setup(process.env.CONNECTION_STRING).start();
/* some customization to auto collect request, console, ... */

const express = require('express');
const app = express();

/* some routes and middleware */

// Handle errors from routes and middleware
app.use( (error, req, res, _next) => {
    const err = ResponseError.fromError(error);

    const response = err.toBaseResponseBody();
    const context = extractContext(req);
    if (context) {
        response.context = {
            id: context.id,
            parent: context.parent
        };
    }

    res.status(err.status).json(response);
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Server listening on port ${port}`) );

function extractContext(req) {
    // Try to extract context generated by app insights to retrieve correlation id and parent correlation id
    // in order to facilitate bug tracking/analysis
}

We try to take a look at response header but, as expected, there is nothing in it. I hope this code could help you to understand what we want to do. The first thing we thought of was to modify the library code to expose the context information in the request object, but if there's something already implemented, let us know.

[JacksonWeber]

@Apokalypt It looks like what you're trying to do here could be achieved with the OpenTelemetry Context. If you want to work with the OpenTelemetry based distro that version 3.X of the SDK is based on, you can get extended functionality from the Azure Monitor OpenTelemetry SDK at the cost of the API compatibility with the Application Insights 2.X SDK.

[Apokalypt]

@Apokalypt It looks like what you're trying to do here could be achieved with the OpenTelemetry Context. If you want to work with the OpenTelemetry based distro that version 3.X of the SDK is based on, you can get extended functionality from the Azure Monitor OpenTelemetry SDK at the cost of the API compatibility with the Application Insights 2.X SDK.

Yes, with version 3.x there's no doubt that it can be done (I've already done it in personal projects). On version 2.x I also saw that there was a getCorrelationContext method that should satisfy this need, but I didn't take the time to test it.

However, to be honest, this idea has been somewhat abandoned by the team I work with. If it ever comes back on the agenda, I'll push through the 3.x update at the same time. In any case, what was requested in this ticket already exists on 3.x and seems to exist in 2.x according to my latest research. I think we can close this ticket 👍