Feature request: Set tags & errors on a root span from a child span

[lukeg-unleashed]

Is your feature request related to a problem? Please describe. I saw that the dd-trace-java APM client has the ability to access the root span for the current trace - this could be very helpful when tagging the trace with important request-specific metadata (e.g. user/account ids).

Describe the solution you'd like Ideally we would have the ability to do something similar to that described here: https://docs.datadoghq.com/tracing/setup_overview/custom_instrumentation/java#set-tags--errors-on-a-root-span-from-a-child-span

Describe alternatives you've considered I've considered using reflection to access the internal Context?.TraceContext?.RootSpan property, but would rather avoid a messy workaround (for hopefully obvious reasons)!

Additional context Please feel free to mention if there's any more detail I can provide.

[fjmorel]

This would be super useful in ASP.NET Core requests in order for code running in subspans to add tags to the root span. For example, I add every feature flag key/value pair as a tag on the request span currently by storing a reference to it at the beginning of the request.

[rparsonsbb]

+1 on this, I'm very surprised that this functionality isn't available out of the box. Are there tips on how to bubble up tags to the root span to be able to search on it?

[davenewza]

Yep, I'll be looking out for this feature 👀 👍

[aforloney]

As a pulse check, is there any update on this?

[mlstubblefield]

+1

[lpodolak]

+1. I realised that by having these 2 spans, we are not able to filter traces by values that are present in both spans. For example, the aspnet_core.request span contains the "status_code", while the aspnet_core_mvc.request constains our custom metadata - e.g. "api.channel". As a result, if we want to filter by both of these values (no matter what we select as the scope: all spans, root spans or service entry spans), we get no results. Which isn't true!

Our problem is that we annotate every request but with values that are present only after data-binding, which means it's already after middleware is executed, hence we land in the "aspnet_core_mvc.request" scope.

I also referenced the problem here

[lpodolak]

What solved the problem in my case is (as @fjmorel suggested) to keep the reference to the root span (aspnet_core.request) and use it later in the MVC pipeline. My only worry is whether this is the safe soluiton.

[mpistrang]

I would benefit from this feature, too!

I'm new to .NET, but I'm pretty sure this is what SetUser() is doing. From what I can tell when it calls into TaggingUtils.GetSpanSetter() the setTag Action that is returned will modify the root span rather than the provided span.

Can a flavor of this be exposed as a public interface in this library?

[pierotibou]

Hello everyone, we have announced at Dash yesterday the private beta for Trace Queries which I believe would solve your use cases as you can look up entire traces based on the tags of multiple spans. You can ask to be part of the private beta (cf the form at the top of the documentation I linked).

From a tracer point of view, we were not pushy to set a tag on a root span from a child span as it comes with extra complexities (version conflicts scenarios are harder to handle, doing it in distributed traces wouldn't work for trace root span...). It was indeed done for the SetUser API for ASM but we'd racer not extend the feature and rely on Trace level queries instead.

Let us know if that works out for you

[Amirault]

Hello Any new's on it ? 🙏 🙏 🙏