Summary

DRIVERS-3598 made each caller-driven getMore its own operation span, sibling to the operation span that created the cursor. Their only correlation is the shared db.mongodb.cursor_id attribute, which OpenTelemetry backends do not render as a relationship. Span links exist for exactly this shape — a causal association between spans that must not be parent and child — and may target a SpanContext in a different trace.

Consider specifying that drivers MAY add a span link from each caller-driven getMore operation span to the span context of the operation span that created the cursor. Raised by nhachicha as a non-blocking follow-up on mongodb/specifications#1973.

Motivation

Who is the affected end user?

Application developers reading traces that involve cursors, and driver teams implementing the spec.

How does this affect the end user?

A find and its getMore}}s appear as unrelated siblings. The causal relationship can only be recovered by comparing {{cursor_id values by hand. When an application holds a cursor across request boundaries the spans land in different traces, where no nesting could ever express the relationship and cursor_id equality is the only tie.

How likely is it that this problem or use case will occur?

Any query returning more than one batch, whenever the cursor is exposed to the caller.

If the problem does occur, what are the consequences and how severe are they?

Minor to moderate. Traces remain complete and correct; the relationship is simply not navigable. No data or availability risk.

Is this issue urgent?

No. Purely additive over DRIVERS-3598.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No. It is a specification addition. Note the unified test format cannot express links today, so how it is covered is one of the open questions below.

Acceptance Criteria

• The spec states the requirement level, and that links complement rather than replace the DRIVERS-3598 rules: nesting, span lifetimes and db.mongodb.cursor_id are unaffected.
• The spec states the direction: from the getMore operation span to the span context of the cursor-creating operation span.
• The spec states that the link is added at span creation rather than afterwards. OpenTelemetry supports adding links later but notes they "may not be considered by Samplers", so only a creation-time link informs head sampling. The creating span context is known at that point, so this is achievable.
• The spec states that retaining the creating span's SpanContext for the cursor's lifetime does not conflict with DRIVERS-3598's rule that no span is scoped to a cursor's lifetime. A SpanContext is an immutable value, not an open span.
• The spec states whether the link carries attributes. OpenTelemetry defines no standard attribute for this relationship.
• The spec states the behaviour for a change stream resume, where the cursor has been re-created by a new aggregate, and confirms driver-internal iteration is out of scope since it produces no getMore operation spans.
• The spec states how this is tested. expectTracingMessages models only name, attributes and nested, so either a prose test or a unified test format addition is required.
• open-telemetry.md has a dated changelog entry.

Pitfalls

Tracing stack support is uneven, which is the main argument for MAY rather than SHOULD. .NET's ActivityLink is supplied when the Activity is created, and Micrometer's Observation API, which the Java driver uses, exposes links poorly. A stronger requirement level may not be implementable everywhere.

A MAY with no test coverage reproduces the pattern DRIVERS-3598 set out to remove: unverified prose that drivers implement differently. Worth deciding deliberately whether that optionality is acceptable, or whether expectTracingMessages should gain a links property first — which would need a unified test format schema version bump and runner support in every driver.