[Question] Should I call SetServiceCallContext(ServiceContext) in multiple places?

[mikanyg]

I am using the Native package to enrich my application insights telemetry, but I have noticed that not all telemetry is enriched with details from the ServiceContext, set by the call FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) at startup in the SF Service class.

Many of our SF microservices use Owin based Web Api Contollers, RabbitMq message handlers and HangFire JobServers, all spawning their own threads, which leads me to think that I need to call the .SetServiceCallContext in more places than just the SF service class itself, to ensure that the CallContext for all threads have set the SF ServiceContext details to be picked up by Application Insights.

So should I call FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) multiple times?

[nizarq]

Hi @mikanyg,
For Owin based api controllers, my experience has been that you just need to set call context when you create service listeners.

However, all FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) does is that it sets a property bag on the logical CallContext. Remember that CallContext is associated with Tasks (not threads - as thread pool threads are a shared resource and any task can be scheduled on a thread), so CallContext will only flow to a particular point in code if it was set upstream either in the current task/sync code or a parent task.

So, your assessment is correct, you may need to play around a bit and make the call in a few other places that lead to the place in code where telemetry is being generated. The original guidance in the readme simply identifies the entry points for out-of-the-box use cases. If you have message handlers and scheduled jobs that do not fit with the boilerplate templates, you should identify entry points and make sure context flows from there.