open-feature
Update the trace support
Currently in the TraceEnricherHook, we're adding tags/events to the current activity,
https://github.com/open-feature/dotnet-sdk/blob/417f3fefbafc656f64069b284f741081b1d77113/src/OpenFeature/Hooks/TraceEnricherHook.cs#L39-L48
In this way, it's hard to listen to the event specifically, since the event is not determined, and sometimes there's no activity.
From the practice on docs, we should create an individual ActivitySource like the Meter, so that we could listen to the ActivitySource when we want to focus on the feature flag activity
https://learn.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs#best-practices
Another thought on the activity, we should try to avoid unnecessary operations to improve performance, for example, we could skip creating and adding tags/events when there's no activity or the Activity.IsAllDataRequested property is false
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.activity.isalldatarequested
Finally, since we're creating a separate ActivitySource, think it could be built-in the main logic other than a hook, the users would need to listen to the ActivitySource explicitly to get related activities, so that no need to register additional trace hook.
I think this is good idea. I would like to keep the current enricher to just enrich in case the user wants to just add the flag evaluation events to the current span.
But, following your request, I think this makes more sense https://github.com/open-feature/dotnet-sdk/discussions/501.
I would prefer to add a trace to the Evaluation method or other important ones where the users would be able to listen to or not. That way, the user wouldn't need to add a new hook, but just configure the telemetry to listen to spans created by the OpenFeature library, which will go well with the best practices article you pointed out.
@open-feature/technical-steering-committee What are your thoughts on this one?
