Context - Stabilization

[scottgerring]

A parent issue to track the stabilization of Context. We've just put a bunch of effort into stabilising the implementation so it can be used to support robust integration with tokio-tracing, and I reckon it makes sense to capitalize on this effort and "fresh knowledge" to make sure the impl matches the spec and there's nothing else in there that's going to jump out at us after we stabilize the API.

An initial review of the implementation against the spec will follow on this issue, and we'll fork out sub-issues for anything that needs more attention.

[cijothomas]

related to it: #2754

[scottgerring]

[From SIG call 11/March/2025] Once the PR for #2754 is closed, we should add to the examples showing how to do context propagation using FutureExt explicitly.

[scottgerring]

Detach Context

his operation is intended to help making sure the correct Context is associated with the caller’s current execution unit. Users can rely on it to identify a wrong call order, i.e. trying to detach a Context that is not the current instance. In this case the operation can emit a signal to warn users of the wrong call order, such as logging an error or returning an error value.

The API MAY return a value used to check whether the operation was successful or not.

There are two conditions where we can detach out of order - firstly, when we try and pop the base pos:

opentelemetry-rust/opentelemetry/src/context.rs

Lines 458 to 463 in 5be79c7

	fn pop_id(&mut self, pos: u16) {
	if pos == ContextStack::BASE_POS || pos == ContextStack::MAX_POS {
	// The empty context is always at the bottom of the [`ContextStack`]
	// and cannot be popped, and the overflow position is invalid, so do
	// nothing.
	return;

Secondly, when we try and pop beyond the stack:

opentelemetry-rust/opentelemetry/src/context.rs

Lines 480 to 483 in 5be79c7

	if pos >= len {
	// This is an invalid id, ignore it.
	return;
	}

This should never happen, and I suggest that we should emit an internal log if it does, 1/ to better meet the OTEL spec and 2/ to help debug what is likely a misuse of the Context.

[scottgerring]

We can also test that context propagation works from parent --> children using FutureExt to propagate, and that context in children is not returned to the parent when the future completes and the context is dropped.

[scottgerring]

@cijothomas , I reckon we've got a good handle on Context and there are no horrors lurking. The parallel work on baggage is going to help too. What do you think?

[cijothomas]

@cijothomas , I reckon we've got a good handle on Context and there are no horrors lurking. The parallel work on baggage is going to help too. What do you think?

Thanks! A key missing piece from Context is #2821 - I want to do some more work to polish this, hence decided to do it after 0.29 release. With that, we'd be in a good state to mark Context as RC next release.

[bantonsson]

With that, we'd be in a good state to mark Context as RC next release.

I think this is a bit early for RC @cijothomas. I would like for the context to have some more functionality, maybe something like the Java ContextStorage or a listener that you could register. This would allow external integrations to provide things like Trace and profiling correlation etc.

[cijothomas]

With that, we'd be in a good state to mark Context as RC next release.

I think this is a bit early for RC @cijothomas. I would like for the context to have some more functionality, maybe something like the Java ContextStorage or a listener that you could register. This would allow external integrations to provide things like Trace and profiling correlation etc.

That's reasonable, but unless they need to break the existing API, no reason not to make Context RC. Additive changes are totally fine after RC/stable.