The code above creates a 'fake' activity on the worker that imitates host activity and allows to omit client/server gRPC spans (which are probably too verbose to be on by default).
If someone listens to all activity sources (AddSource("*")) , both host and worker activity will be generated. They have identical ids, that may or may not be supported by the tooling.
@lmolkova do you know if there is something we can do in the meantime until OTel has its spec? Can we add a tag to our span to tell everyone to ignore it?
https://github.com/Azure/azure-functions-dotnet-worker/blob/2b83c355eaa21f508f9ff7a46bdc8e953e592527/src/DotNetWorker.Core/FunctionsApplication.cs#L80
The code above creates a 'fake' activity on the worker that imitates host activity and allows to omit client/server gRPC spans (which are probably too verbose to be on by default).
This behavior is the best that's possible today dues to limitations: https://github.com/open-telemetry/opentelemetry-dotnet/issues/5286 and the underlying https://github.com/dotnet/runtime/issues/86966. Which get no traction because of https://github.com/open-telemetry/opentelemetry-specification/issues/4271
Unfortunately it leads to fun issues such as https://github.com/dotnet/aspire/issues/6441.
If someone listens to all activity sources (
AddSource("*")
) , both host and worker activity will be generated. They have identical ids, that may or may not be supported by the tooling.I don't see how anything can be solved on the Functions side until https://github.com/open-telemetry/opentelemetry-specification/issues/4271 is done. I'll try to update the spec.