SDK: Forward SetParentProvider to children of CompositeProcessor

[CodeBlanch]

Changes

Forward SetParentProvider calls to child processors when using CompositeProcessor.

TODOs

• Appropriate CHANGELOG.md updated for non-trivial changes
• Tests

[CodeBlanch]

@alanwest You mentioned something on SIG about ParentProvider not working with custom processors. Think this could be why?

[reyang]

LGTM with a changelog (adding a unit test would be even better).

[codecov]

Codecov Report

Merging #3368 (e9e4379) into main (8b1521f) will increase coverage by 0.24%.
The diff coverage is 95.83%.

@@            Coverage Diff             @@
##             main    #3368      +/-   ##
==========================================
+ Coverage   85.80%   86.04%   +0.24%     
==========================================
  Files         268      268              
  Lines        9444     9460      +16     
==========================================
+ Hits         8103     8140      +37     
+ Misses       1341     1320      -21     

Impacted Files	Coverage Δ
...rter.InMemory/InMemoryExporterLoggingExtensions.cs	90.90% <88.88%> (-9.10%)	⬇️
...penTelemetry.Exporter.InMemory/InMemoryExporter.cs	92.30% <100.00%> (ø)
...rter.InMemory/InMemoryExporterMetricsExtensions.cs	97.50% <100.00%> (ø)
src/OpenTelemetry/CompositeProcessor.cs	95.31% <100.00%> (+0.31%)	⬆️
.../OpenTelemetry/Logs/OpenTelemetryLoggerProvider.cs	94.44% <100.00%> (+0.21%)	⬆️
src/OpenTelemetry/Trace/TracerProviderSdk.cs	96.42% <100.00%> (+0.02%)	⬆️
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs	76.47% <0.00%> (+2.94%)	⬆️
...metryProtocol/Implementation/ActivityExtensions.cs	94.50% <0.00%> (+3.29%)	⬆️
...xporter.OpenTelemetryProtocol/OtlpTraceExporter.cs	77.27% <0.00%> (+40.90%)	⬆️
...entation/ExportClient/OtlpGrpcTraceExportClient.cs	78.57% <0.00%> (+42.85%)	⬆️

[cijothomas]

@alanwest You mentioned something on SIG about ParentProvider not working with custom processors. Think this could be why?

#3241 This!
@vishweshbankwar You have also reported the same earlier.

[alanwest]

Yes, this is a good fix.

Technically it resolves the initial issue that led to #3241, I think we can close it if we want. I still think the use case of filtering spans from getting exported may be better served by an example of a filtering exporter, but I can see the value of the filtering processor as well.

[CodeBlanch]

So this fix actually won't help the MyFilteringProcessor referenced on #3241 😢 Because it is hiding the inner processor on a field.

We could make internal virtual void SetParentProvider(BaseProvider parentProvider) public to allow that processor to forward the set to its inner processor field. Or we could rewrite the sample like this, and then it would work:

internal class MyFilteringProcessor : CompositeProcessor<Activity>
{
    private readonly Func<Activity, bool> filter;

    public MyFilteringProcessor(BaseProcessor<Activity> processor, Func<Activity, bool> filter)
        : base(new[] { processor })
    {
        this.filter = filter ?? throw new ArgumentNullException(nameof(filter));
    }

    public override void OnEnd(Activity activity)
    {
        // Call the underlying processor
        // only if the Filter returns true.
        if (this.filter(activity))
        {
            base.OnEnd(activity);
        }
    }
}

[alanwest]

Oh good call, thanks you've jogged my memory of the problem here.

Or we could rewrite the sample like this

Yes! Personally, I like this idea idea over making SetParentProvider public. Pretty sure this whole concept of a parent provider is kind of a .NET specific need, so I guess I'm inclined to keep its public surface area small if possible.

[CodeBlanch]

I like this idea idea over making SetParentProvider public.

I'm good with that I'll do as a follow-up.