Summary

The spec requires each command span to nest under "the corresponding driver operation span", which is unambiguous only while an operation sends a single command. For a cursor it never says which operation span a getMore belongs to: one span covering the cursor's whole lifetime, or a fresh one per iteration. Both readings pass the current suite, since no fixture exercises getMore, batchSize or a tailable cursor, and db.mongodb.cursor_id is asserted absent in all 25 places it appears.

Motivation

Who is the affected end user?

Driver teams implementing the spec, and application developers reading the traces.

How does this affect the end user?

Drivers can pick either nesting and still pass, so trace shapes for a very common operation differ by language with no way to tell which is correct.

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

Main path. Any query returning more than one batch sends a getMore.

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

Moderate. No outage or data risk, but cross-language traces become hard to compare, and a driver that guessed differently needs a breaking change to its span structure later.

Is this issue urgent?

No, but it is cheaper to settle before more drivers ship.

Is this ticket only for tests?

No. It needs a spec clarification too, since a test alone would make one reading of ambiguous prose normative.

Acceptance Criteria

• The spec states which operation span a getMore nests under, and what is expected for cursors that are never exhausted, where a lifetime-scoped span would never end.
• A test covers a query returning more than one batch and asserts the getMore nesting, with extra spans not ignored so an unintended operation span per batch fails.
• A test asserts db.mongodb.cursor_id is present, on both a cursor-creating command and one that uses an existing cursor.