Skip to main content
OpenTelemetry tracks the current span via a context — an immutable object that holds the active span’s ID, trace ID, and a few other pieces of metadata. When you call tracer.start_as_current_span(...), OTel reads the current context, sets the new span as a child, and updates the context. Within a single thread of execution, this is automatic. Across threads, async boundaries, or service boundaries, the context doesn’t follow on its own — you have to propagate it.

The Context Object

Every span carries an immutable Context object containing: Baggage is the channel for non-tracing data that should follow the request — feature flags, tenant IDs, request type. Baggage doesn’t become span attributes automatically; if you want it on spans, you have to read it and set it explicitly.

When Propagation Is Needed (and When It Isn’t)

Most application code falls into the left column — context propagation just works. The right column is where you need the propagators below.

Automatic Propagation

In Python, OTel uses contextvars under the hood, which propagates context cleanly across:
  • Synchronous function calls.
  • asyncio tasks within the same event loop.
  • await boundaries.
You don’t have to do anything special — tracer.start_as_current_span(...) works as you’d expect.

Manual Context Propagation

When automatic propagation breaks down — across threads, across services, into background workers — these are the tools OTel gives you: DefaultTextMapPropagator() is a convenience symbol in the Python opentelemetry-api package that constructs a composite propagator combining: The OTel specification doesn’t define a propagator named DefaultTextMapPropagator — it just requires that SDKs default to a composite of the W3C Trace Context and Baggage propagators. JS/Go/Java equivalents construct the same composite under slightly different names; check the Propagators spec for your language. For the Python API reference, see OpenTelemetry Context API and Propagators API.

Async Functions (Same Service)

When you launch async work from sync code, the context doesn’t always follow. Capture it explicitly:
The pattern:
  1. Capture the current context before launching async work: context = get_current().
  2. Pass the context into the async function.
  3. Inside the async function, attach(ctx) and store the returned token.
  4. In a finally, detach(token) to restore the previous context.
For more patterns including ThreadPoolExecutor, see Advanced Patterns: Manual Context Propagation.

Across Microservices

Crossing a service boundary is where propagators earn their keep. Service A injects the current context into outbound request headers; Service B extracts it on the inbound side and uses it as the parent for its own spans. Service A (caller):
Service B (callee):
After this, Service B’s span appears as a child of Service A’s span — even though they ran in different processes — and both appear under the same trace ID in the Arize AX UI.

Common Propagation Failure Modes

A few patterns that produce orphaned or broken traces:
  • Forgetting to inject context on the caller side — the callee starts a new trace instead of joining the existing one. Symptom: caller and callee appear as separate traces in the Arize AX UI.
  • Using different propagators on each side — if Service A injects W3C headers and Service B only extracts a different format, the context is silently lost. Stick with DefaultTextMapPropagator() everywhere unless you have a specific reason not to.
  • Stripping headers in the network layer — proxies, API gateways, and service meshes sometimes strip headers they don’t recognize. The W3C traceparent header is usually safe but verify with your infrastructure team.
  • Async work that escapes the request lifecycle — fire-and-forget tasks (background workers, queues) need explicit context capture before submission.

Next step

Context propagation is about making sure spans are connected. Sampling is about which spans get recorded at all:

Next: Sampling