Joining a conversation that's currently happening across two PRs:

• ext/wsgi: use current span when extracting fails #226 (comment)
• Feature/tracecontext integration test #228 (review)

It's important for us to standardize on what httptextformatters will return back when they are unable to parse the span context from their respective headers. If the choice is to return an invalid span context, then we should figure out what is responsible for handling that condition, and what the correct behavior is.

Proposal

As a start, I'm proposing:

1. if a formatter is unable to retrieve a valid spancontext, then an invalid spancontext should be returned.
2. this should be handled in the propagator shim: https://github.com/open-telemetry/opentelemetry-python/blob/master/opentelemetry-api/src/opentelemetry/propagators/__init__.py#L26 and return back tracer.CURRENT_SPAN.

Here's alternatives and why I'm arguing against them:

Handling invalid spans in the integrations

Handling this in the integrations would require the same boilerplate code to handle and convert the invalid span into the CURRENT_SPAN constant. I worry about someone missing that implementation detail resulting in incongruent behavior.

Handling invalid spans in the SDK

I'm not 100% clear on what this would look like, but it would probably require making propagators and API interface and moving implementation code into the SDK. Not including this behavior would mean that the API alone is not enough to implement correct w3c tracecontext propagation (as invalid span contexts would not be converted to new ones).

I'm having trouble finding where it was stated that the API should propagate tracecontext by defaults. Maybe @c24t or @reyang can point me in the right direction?