Make SpanProcessor.on_start accept parent Context

[mariojonke]

Description

Adds optional parent Context parameter to SpanProcessor.on_start as per spec.

Fixes #1250

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

Additional unit tests checking that the parent Context is passed through from tracer.start_span to SpanProcessor.on_start

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[lzchen]

I understand that this is in the specs but what exactly is it being used for? I don't see the behavior being defined anywhere (or where this parameter is being used) specifically for SpanProcessor. @Oberon00 any thoughts on this?

[Oberon00]

@lzchen

I don't see the behavior being defined anywhere

Which behavior do you mean? It is clearly specified what must be in there: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#OnStart

what exactly is it being used for

This is not used in the built-in SDK, but one usage example from Dynatrace is this: We have a custom propagator that reads an additional HTTP header. We set this http header in the returned context. In a custom SpanProcessor we can copy the header from the context to a span attribute, in order to later have it exported.

[Oberon00]

@mariojonke

New feature (non-breaking change which adds functionality)

This changes the SpanProcessor interface, so it is breaking I think.

[lzchen]

@Oberon00

Which behavior do you mean?

Sorry what I meant was:
If the default SDK is expected to use this parameter somewhere, the behavior isn't defined anywhere.

This is not used in the built-in SDK

If it is not used in the built-in SDK, why define Onstart with this parameter in the default SDK? Shouldn't your custom SpanProcessor have this method signature instead, and whatever implementation of Span should have self.span_processor.on_end(self, context)? Unless if I'm mistaken about how to actually use this.

[Oberon00]

If it is not used in the built-in SDK, why define Onstart with this parameter in the default SDK?

Because one purpose of the built-in SDK is to allow users to add custom span processors which might need this parameter 😃

Shouldn't your custom SpanProcessor have this method signature instead, and whatever implementation of Span should have self.span_processor.on_end(self, context)

(you mean on_start here, right?)
"Whatever implementation of Span" is the default SDKs implementation. One doesn't need to implement a custom span to use a custom SpanProcessor.

[Oberon00]

Note that Dynatrace is not the only party interested in this, as evident e.g. from open-telemetry/opentelemetry-java#1811

[lzchen]

@Oberon00

"Whatever implementation of Span" is the default SDKs implementation.

Ahh I see that was the confusion. Thanks for the explanation! :)

[lzchen]

What's this change for?

[mariojonke]

when running the test locally with the eachdist script this test fails. The problem is that there are some entry points already setup when installing a dev environment with eachdist develop. This test however checkes the default error handler when no error handler entry points are configured.

[mariojonke]

@Oberon00

@mariojonke

New feature (non-breaking change which adds functionality)

This changes the SpanProcessor interface, so it is breaking I think.

calling on_start without parent_context should still work as before since it is an optional parameter (unless i overlooked something)
on a second thought it is a breaking change after all since the tracer now explicitly passes the parent_context explicitly to the SpanProcessor

[codeboten]

Thanks for the change, lgtm