tracing-opentelemetry: Add opentelemetry::Context propagation

[mkatychev]

Motivation

After some discussion as to the motivation of this PR: open-telemetry/opentelemetry-rust#893

an alternative solution was proposed for allowing spans to implicitly propagate otel context:

Allow spans to propagate and drop otel context IDs when spans are entered and exited

Solution

Add otel::Context to OpenTelemetrySubscriber for on_enter and on_exit

[mkatychev]

inner_span is not holding a parent, this currently evaluates to None:

tracing/tracing-opentelemetry/src/subscriber.rs

Line 591 in eca60a6

if let Some(parent) = attrs.parent() {

[mkatychev]

@jtescher any thoughts as to why the test is preventing a Span::child_of to be built on macro invocation?

tracing/tracing/src/macros.rs

Lines 71 to 76 in eca60a6

	let meta = CALLSITE.metadata();
	// span with contextual parent
	$crate::Span::new(
	meta,
	&$crate::valueset!(meta.fields(), $($fields)*),
	)

Am I missing something in the test harness?

tracing/tracing-opentelemetry/src/subscriber.rs

Lines 1232 to 1254 in eca60a6

	let _outer_g = outer_span.enter();
	let inner_span = tracing::debug_span!("inner");
	dbg!(OtelContext::current().span().span_context().trace_id());
	dbg!(OtelContext::current().has_active_span(),);
	dbg!(outer_span.context().has_active_span(),);
	dbg!(outer_span.context().span().span_context().trace_id());
	// let inner_span = tracing::debug_span!("inner");
	dbg!(tracing::Span::current().id().unwrap());
	assert_eq!(
	OtelContext::current().span().span_context().trace_id(),
	trace_id
	);
	let _inner_g = inner_span.enter();
	assert_eq!(
	OtelContext::current().span().span_context().trace_id(),
	trace_id
	);
	dbg!(tracing::Span::current().id().unwrap());
	});
	// let recorded_trace_id =

These are the logs:

[tracing-opentelemetry/src/subscriber.rs:681] id = Id(
    2,
)
[tracing-opentelemetry/src/subscriber.rs:682] attrs = Attributes {
    metadata: Metadata {
        name: "inner",
        target: "tracing_opentelemetry::subscriber::tests",
        level: Level(
            Debug,
        ),
        module_path: "tracing_opentelemetry::subscriber::tests",
        location: tracing-opentelemetry/src/subscriber.rs:1246,
        fields: {},
        callsite: Identifier(0x10518c330),
        kind: Kind(SPAN),
    },
    values: ValueSet {
        callsite: Identifier(0x10518c330),
    },
    parent: Current,
}
[tracing-opentelemetry/src/subscriber.rs:590] "parent" = "parent"
[tracing-opentelemetry/src/subscriber.rs:592] attrs.parent().is_some() = false
on_enter attaching trace id: 00000000000000000000000000000000
thread 'subscriber::tests::trace_id_propagates_to_current_context' panicked at 'assertion failed: `(left == right)`
  left: `00000000000000000000000000000000`,
 right: `0000000000000000000000000000002a`', tracing-opentelemetry/src/subscriber.rs:1247:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
on_exit dropping trace id: 00000000000000000000000000000000
on_exit dropping trace id: 0000000000000000000000000000002a
test subscriber::tests::trace_id_propagates_to_current_context ... FAILED

[jtescher]

Hm this approach may actually have to be re-assessed, dropping the otel context guards will replace the previously active context so the order dependence of entering and exiting will likely cause issues.

[mkatychev]

Hm this approach may actually have to be re-assessed, dropping the otel context guards will replace the previously active context so the order dependence of entering and exiting will likely cause issues.

Would having access to the previous_cx field on ContextGuard help this? I assume your concern is that dropping a context guard does not always follow a FILO pattern.