Summary

Follow-up to the OTel db.operation.name work: the "Covered operations" table has several entries that don't match their MongoDB command name, two doc links are swapped, collection-level bulkWrite is unspecified, and two operations (countDocuments, rename) are missing from the table entirely.

Background

The spec implies db.operation.name follows the command name (see the findOneAndDelete/findAndModify note), and upstream OTel's MongoDB semantic conventions agree. Four of the 23 table entries deviate from their command name:

• createCollection (command: create)
• dropCollection (command: drop)
• estimatedDocumentCount (command: count)
• withTransaction (no command at all)

Proposed changes

Document, don't rename:

• createCollection and dropCollection appear to be oversights, but renaming now would cause churn across driver releases and require skip conditions in unified tests. Document the discrepancy in the table instead of renaming.
• withTransaction has no underlying command and should be called out as an outlier.

Rename in the table:

• estimatedDocumentCount is the CRUD spec helper name, but the operation name we actually use is count. Update the table entry to count and call out the discrepancy.

Fix broken links:

• The last two rows have swapped links: updateSearchIndex points to delete.yml and delete points to atlas_search.yml. Fix both.

Add missing operations:

• countDocuments is not currently covered. Propose adding it as countDocuments rather than its underlying command. The CRUD spec mandates it be implemented as a $group aggregate, so naming it after the command would make it indistinguishable from a real aggregation, and naming it count defeats the purpose of the CRUD spec's disambiguation. countDocuments is the spec helper name used consistently across drivers, and the nested aggregate command span still records what actually went on the wire.
• rename is not currently covered. Its command is renameCollection; without a table entry and test coverage, drivers are free to pick different spellings with nothing to catch the divergence.

Collection-level bulkWrite:

• bulk_write.yml covers only the client-level helper; collection-level bulkWrite is unspecified. Collection bulkWrite sends insert, update, and delete commands, so no single command name applies, and PyMongo currently reports insert regardless of batch contents (a delete-only bulk write incorrectly traces as insert – this should be fixed regardless of the naming outcome).
  • Proposal: name it bulkWrite, matching the public API method and the client-level operation name. This stays unambiguous because db.namespace is the collection rather than admin, and the real commands still appear as nested spans.
  • Alternative: OTel's batch convention – BATCH for mixed-command batches, BATCH insert for uniform ones.
  • Alternative: for a uniform batch (all one command), name it bulkWrite insert/bulkWrite update/bulkWrite delete to mirror command-name-based naming elsewhere; mixed batches fall back to plain bulkWrite.

Scope

This should land as a single PR that updates the spec's "Covered operations" table (documentation of discrepancies, renames, link fixes, new rows for countDocuments and rename), decides the collection-level bulkWrite naming, fixes the PyMongo command-name-reporting bug for collection bulkWrite, and adds test coverage for renameCollection, countDocuments, and the different forms of collection-level bulkWrite (insert-only, update-only, delete-only, and mixed).