[nhachicha]

Summary

This documentation-only change explains how servers may handle trace context sent by drivers. Servers may ignore it if tracing is disabled. If tracing is enabled, they may continue sampled traces, but can still drop them due to rate limits. The trace context does not appear in server diagnostics such as logs or the profiler. Drivers must continue sending it on every eligible command, as already required.

Source

Server behavior confirmed by the server OpenTelemetry owner in this SERVER-137033 comment (2026-10-22).

Related

This is documentation-only and follows up on:

• DRIVERS-3454 Support trace context propagation to the server #1966 (DRIVERS-3454, which added trace context propagation to the server)

• DRIVERS-3620 Add Performance Implications section to the OpenTelemetry spec #1986 (DRIVERS-3620, the Performance Implications section)

• Update changelog.

• 1st implementation completed and tests pass.

• 2nd implementation completed and tests pass.

• Test these changes against all server versions and topologies (including standalone, replica set, and sharded
  clusters).

[Copilot]

🔵 Needs a closer look

The server behavior assertions require human confirmation against the linked Jira source, which was not independently verified.

1 open issue

• Add DRIVERS ticket key to the PR title · New

What changed in this PR

Adds non-normative server-side context to the OpenTelemetry specification, complementing existing driver trace propagation requirements without changing them.

Changes:

• Describes when servers ignore, continue, or rate-limit propagated traces.
• Clarifies that propagated trace context is not exposed in server diagnostics.
• Restates existing driver propagation requirements and adds a changelog entry.

File	Description
source/​open-telemetry/​open-telemetry.md	Adds “Expected Server Behavior” guidance and records the documentation update.

_{Review effort: Balanced}