Populate Cosmos operation_name + active_instance metric

[Nalu Tripician (NaluTripician)]

Why

Two enrichment gaps in the merged Cosmos observability layer (#4789): DiagnosticsContext::operation_name was never populated in production (so tail-sampling's point-vs-non-point classification and the db.operation.name span label were degraded), and the azure.cosmosdb.client.active_instance.count metric was documented but not emitted.

What

operation_name plumbing (azure_data_cosmos_driver)

• CosmosOperation::db_operation_name() maps (operation type, resource type, feed scope) to the canonical OTel db.operation.name values — read_item / create_item / replace_item / upsert_item / delete_item / patch_item / query_items / query_change_feed / execute_batch / container + database ops, and read_all_items vs read_all_items_of_logical_partition depending on whether the read feed's FeedRange is scoped to one logical partition. Unmapped internal ops (query plans, pk-range reads, HEAD, sprocs, DTX) stay None.
• Throughput (offer) operations are deliberately left unmapped. Semconv has no unscoped read_throughput; it distinguishes read_database_throughput from read_container_throughput, and an offer request carries no database-vs-container discriminator, so the driver cannot pick correctly. The scoped names are supplied by the SDK's DatabaseClient/ContainerClient throughput operations, which do know the scope.
• DiagnosticsContextBuilder gains an operation_name field + setter, propagated through clone_for_hedge_attempt and complete() (previously hardcoded None), set at the single operation-scope chokepoint in execute_operation_direct.
• PATCH is a read-modify-write, so its diagnostics would otherwise surface the trailing internal Replace. Every exit — the success aggregate, retry exhaustion, and each error path (read, missing-ETag, body extraction, deserialize, patch evaluation, serialize, non-412 replace) — now routes through a helper that merges prior attempts and stamps patch_item.

active_instance.count (azure_data_cosmos, opt-in)

• New MetricsOptions::with_active_instance_metric, backed by an i64 up-down counter keyed on the account endpoint (server.address, plus server.port only for a non-default port) — the semconv attribute set for this instrument.
• Counting follows clients, not handlers. DiagnosticsHandler gains a defaulted on_client_created(&CosmosClientInfo) -> Option<ClientLifetimeToken> hook, dispatched once per client by ClientContext::new. CosmosMetricsHandler records the +1 there and returns a token whose Drop records the -1. ClientContext owns the token and is cloned down into every DatabaseClient/ContainerClient, so the -1 lands when the last client derived from that CosmosClient goes away. A handler shared across N clients therefore reports N, and one registered on no client reports nothing.
• The default hook returns None, so existing handlers are unaffected and it costs nothing when unused.

Tracing span label

The span's operation label now prefers the caller-facing CosmosOperationContext identity over the driver-recorded name, matching how the db.operation.name metric attribute is resolved. Previously a PATCH that failed during its internal read could label the span read_item while the metric reported patch_item.

Notes

• Additive and non-breaking; active_instance is opt-in.
• DIAGNOSTICS-CONTRACT.md is corrected in two places: the D10 note claimed this counter is keyed on azure.client.id, which is a span attribute and would make every series a constant 1; and §10.3.1 now records the throughput-scope split above.
• Deferred (not in this PR): the tracing → azure_core-backdating-trait migration is blocked on core 1.2.0 being published (shipping crates link published core 1.1.0); request-scope (per gateway/replica) metrics remain a documented high-cardinality follow-up.

Verification

• cargo fmt --check clean; cargo clippy --all-targets on both crates (SDK with metrics,distributed_tracing,control_plane,key_auth; driver with fault_injection) — 0 warnings.
• cargo test -p azure_data_cosmos_driver --lib (2362 pass, incl. the db_operation_name mapping and PATCH error-path label tests); cargo test -p azure_data_cosmos --lib --doc (179 + 50 pass, incl. the active-instance lifecycle, endpoint-keying, and handler-chain dedup tests). --all-features skipped (environmental openssl-sys).

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Populates Cosmos operation names for diagnostics and adds opt-in active-client metrics.

Changes:

• Maps driver operations to OpenTelemetry names.
• Propagates names through diagnostics, including PATCH aggregation.
• Adds active-instance metric configuration and lifecycle accounting.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
metrics/options.rs	Adds the active-instance option.
metrics/instruments.rs	Defines the up-down counter.
metrics/handler.rs	Emits lifecycle count changes.
metrics/attributes.rs	Adds metric constants.
azure_data_cosmos/CHANGELOG.md	Updates metrics release notes.
cosmos_operation.rs	Maps operation names.
patch_handler.rs	Labels aggregated PATCH diagnostics.
cosmos_driver.rs	Populates operation names.
diagnostics_context.rs	Stores and propagates operation names.
DIAGNOSTICS-CONTRACT.md	Documents metric emission.
azure_data_cosmos_driver/CHANGELOG.md	Documents driver changes.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/handler.rs:99

• This increments the “active client instance” metric when a handler is constructed, even if it is never registered with a client; conversely, one Arc<CosmosMetricsHandler> can be registered with multiple independently built clients and contributes only 1. Because the public registration API accepts a shareable Arc<dyn DiagnosticsHandler>, handler lifetime is not a reliable proxy for client lifetime, so this metric can over- or under-count clients. Tie the increment/decrement to client construction and the shared client-instance lifetime instead.

        if handler.options.active_instance_metric_enabled() {
            handler
                .instruments
                .active_instance
                .add(1, &Self::active_instance_attributes());

sdk/cosmos/azure_data_cosmos/CHANGELOG.md:8

• The new with_active_instance_metric public API is buried inside the existing #4789 handler entry. Give this distinct public API addition its own concise line so users can identify what #4874 adds without parsing or attributing the entire older feature to both PRs.

- Added the `metrics`-gated `CosmosMetricsHandler` (with `MetricsOptions`), emitting the stable `db.client.operation.duration` histogram plus per-signal opt-in metrics (`with_request_charge_metric`, `with_returned_rows_metric`, and `with_active_instance_metric` — an `azure.cosmosdb.client.active_instance.count` up-down counter that is incremented on handler construction and decremented on drop to track live client instances) and an opt-in extended attribute set (`with_extended_attributes`); a no-op when no meter provider is registered. ([#4789](https://github.com/Azure/azure-sdk-for-rust/pull/4789), [#4874](https://github.com/Azure/azure-sdk-for-rust/pull/4874))

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (3)

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/handler.rs:99

• This increments at handler construction, not when a client is created. The public registration API accepts an Arc<dyn DiagnosticsHandler>, so an enabled handler can be constructed but never registered, shared by multiple independently built clients, or registered more than once; all of those supported cases make this "active client instance" metric incorrect. Move the +1/-1 accounting to a per-built-client registration/lifetime guard (shared by that client's clones) so each instrumented client contributes exactly once.

        if handler.options.active_instance_metric_enabled() {
            handler
                .instruments
                .active_instance
                .add(1, &Self::active_instance_attributes());

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/diagnostics_context.rs:2245

• This updated public documentation now says production contexts carry the operation name, but the same API's is_threshold_violated_for documentation at lines 2311-2316 still says production contexts do not carry one and that SDK handlers must supply it. Update that stale section so rustdoc does not present contradictory behavior.

    /// `create_item`, or `query_items`. The driver pipeline populates this from
    /// [`CosmosOperation::db_operation_name`](crate::models::CosmosOperation::db_operation_name);
    /// it is `None` only for operations without a canonical name (query plans,
    /// partition-key-range reads, and other internal requests).

sdk/cosmos/azure_data_cosmos_driver/CHANGELOG.md:7

• This release note combines the new public method, pipeline behavior, tracing precedence, and PATCH aggregation into a very long implementation-level entry. The changelog guidance requires a concise one-line summary of each public API change; keep the customer-visible db_operation_name/diagnostics behavior and omit internal tracing details.

- Added `CosmosOperation::db_operation_name`, returning the canonical OpenTelemetry `db.operation.name` (e.g. `read_item`, `query_items`, `execute_batch`) for an operation. The operation pipeline now populates `DiagnosticsContext::operation_name` from it in production (previously always `None`), so `DiagnosticsContext::operation_name()` is populated for callers inspecting diagnostics and supplies the operation name to the emission layer's tail-sampling classifier and tracing span when no SDK-supplied `CosmosOperationContext` is present. The tracing span's operation label prefers the caller-facing `CosmosOperationContext` identity (consistent with the `db.operation.name` metric), and PATCH aggregates report `patch_item` rather than the underlying Replace. ([#4874](https://github.com/Azure/azure-sdk-for-rust/pull/4874))

[Copilot]

Pull request overview

Copilot reviewed 21 out of 22 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/handler.rs:300

• Every registered CosmosMetricsHandler executes this +1 because DiagnosticsHandlerChain::dispatch_client_created visits the entire chain. Since repeated with_diagnostics_handler calls are explicitly supported (src/options/client.rs:44-47), one client with two metrics handlers backed by the same meter—or the same handler registered twice—reports 2 active clients. This contradicts the metric's client-instance semantics and the documented claim that the value is independent of handler count. Deduplicate this registration per logical client/instrument, or enforce a single metrics handler before recording.

        counter.add(1, &attributes);

sdk/cosmos/azure_data_cosmos_driver/CHANGELOG.md:15

• This tracing-span behavior is implemented in azure_data_cosmos/src/diagnostics/tracing/span_builder.rs, not in the driver crate. Listing it in the driver changelog misstates what driver-only users receive, while the SDK changelog omits the fix. Move this entry to the SDK changelog's existing Bugs Fixed section.

- The tracing span's operation label now prefers the caller-facing `CosmosOperationContext` identity, matching how the `db.operation.name` metric attribute is resolved. ([#4874](https://github.com/Azure/azure-sdk-for-rust/pull/4874))

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/handler.rs:420

• The embedded second /// makes this generated test documentation read as one malformed line. Split it into two doc-comment lines.

    /// Returns the summed value of the `active_instance.count` up-down counter    /// from the most recent export, or `None` if the metric was never emitted.

[Nalu Tripician (NaluTripician)]

Rebased onto main and picked up the three review points that were raised in the last pass but left open.

Merge conflict

Merged upstream/main (through #4844 / #4855 / #4904). One conflict, in azure_data_cosmos_driver/CHANGELOG.md: main added the PlanOptions fan-out bullet (#4855) and this branch added the CosmosOperation::db_operation_name bullet (#4874) at the same position under Features Added. Both are kept. No source conflicts — cargo build, clippy --all-targets, and the full test suites are clean against the merged tree.

Active-instance count with a repeated handler

DiagnosticsHandlerChain::dispatch_client_created visited every chain entry, so registering the same Arc<dyn DiagnosticsHandler> twice — reachable, since with_diagnostics_handler is additive — recorded two +1s for one client and reported it as two live instances.

Client creation is a per-client lifecycle event rather than a per-call dispatch, so the chain now notifies each distinct handler at most once per client, deduplicating by Arc identity. Distinct handler objects are still notified independently, since they are separate sinks. Three tests pin it: client_created_notifies_a_repeated_handler_once, client_created_notifies_distinct_handlers_independently, and client_created_is_noop_for_handlers_that_do_not_track_lifetime.

The related doc claim was also an overreach. DIAGNOSTICS-CONTRACT.md said the counter was "independent of how many handler objects exist", but two distinct metrics handlers built from the same meter each record their own +1 — exactly as they each record their own duration and request-charge samples, so that is general handler-chain behavior rather than something specific to this counter. The contract now states what is actually guaranteed (one handler across N clients reports N; a handler registered on no client reports nothing), and MetricsOptions::with_active_instance_metric points users at one metrics handler per meter.

Changelog placement

The tracing-span operation-label precedence entry was under the driver's Bugs Fixed, but that behavior lives in azure_data_cosmos/src/diagnostics/tracing/span_builder.rs. Listing it in the driver changelog misstates what driver-only consumers receive, so it moved to the SDK changelog with the symptom spelled out (a PATCH failing during its internal read could label the span read_item while the metric reported patch_item).

Doc comment

Split the active_instance_value test helper's doc comment, which had two /// prefixes collapsed onto one line.

Verification

cargo fmt --check clean. clippy --all-targets on both crates (SDK with metrics,distributed_tracing,control_plane,key_auth; driver with fault_injection) — 0 warnings. azure_data_cosmos_driver --lib: 2362 passed. azure_data_cosmos --lib: 179 passed. --doc: 50 passed.

[Ashley Stanton-Nurse (analogrelay)]

Approving, but let's consider a brief discussion offline about what db.operation.name should be for patch elements (read/replace)

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

sdk/cosmos/azure_data_cosmos_driver/src/driver/pipeline/patch_handler.rs:472

• For locally synthesized failures after a successful Read (missing ETag, body extraction/deserialization, patch evaluation, or serialization), sources contains only successful sub-operation diagnostics. Reusing that context while changing only the name leaves its operation/terminal status successful, so DiagnosticsContext::is_failure() is false and effective_status() reports 200. The tracing/logging handlers can therefore suppress the failed PATCH and metrics label it as a success. Stamp err.status() onto the replacement diagnostics as well as patch_item, and add a local-error assertion for the diagnostics status/failure classification.

    let stamped = match sources.as_slice() {
        [] => return err,
        [only] => Arc::new(only.clone_with_operation_name(operation_name)),
        many => match DiagnosticsContext::aggregate_sub_operations(many) {
            Some(ctx) => Arc::new(ctx.with_operation_name(operation_name)),

sdk/cosmos/azure_data_cosmos/src/diagnostics/handler.rs:172

• The new default hook is swallowed by the existing composable SamplingLogHandler: that wrapper delegates handle to its inner DiagnosticsHandler but does not override and forward on_client_created. Consequently, wrapping an active-instance-enabled CosmosMetricsHandler causes the counter to emit nothing even though the inner handler is registered through the wrapper. Forward this lifecycle hook (and its token) through handler decorators, with a wrapper test.

    fn on_client_created(&self, client: &CosmosClientInfo) -> Option<ClientLifetimeToken> {
        let _ = client;
        None

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/attributes.rs:37

• This description contradicts the implementation: the instrument counts live CosmosClient instances, not CosmosMetricsHandler instances; one shared handler can count multiple clients. Describe the measured client lifetime instead.

/// Optional up-down counter (instances): number of live
/// [`CosmosMetricsHandler`](super::CosmosMetricsHandler) instances (one per
/// instrumented client, under the intended one-handler-per-client registration).

[Copilot]

Pull request overview

Copilot reviewed 21 out of 21 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (6)

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/attributes.rs:37

• This comment still describes handler instances, but the implementation now deliberately counts logical clients and supports one handler shared by multiple clients. Document the client-based series here so this constant does not contradict the public option and handler docs.

/// Optional up-down counter (instances): number of live
/// [`CosmosMetricsHandler`](super::CosmosMetricsHandler) instances (one per
/// instrumented client, under the intended one-handler-per-client registration).

sdk/cosmos/azure_data_cosmos/src/diagnostics/handler.rs:173

• The new default hook is swallowed by the built-in SamplingLogHandler, even though that wrapper accepts any Arc<dyn DiagnosticsHandler> and delegates handle to it. Wrapping a lifecycle-aware handler (including CosmosMetricsHandler) therefore prevents its on_client_created callback and the active-instance metric never increments. Add an override on SamplingLogHandler that forwards this lifecycle callback to its inner handler.

    fn on_client_created(&self, client: &CosmosClientInfo) -> Option<ClientLifetimeToken> {
        let _ = client;
        None
    }

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/diagnostics_context.rs:2076

• aggregate_sub_operations is also used for retries of the same operation by CosmosResponse::with_aggregated_prior_diagnostics (src/models/cosmos_response.rs:197-207). This unconditional assignment therefore populates every request with a redundant name even when all sources are the same operation, contradicting the new accessor contract that the field is set only for multi-operation aggregates and changing ordinary retry diagnostics JSON. Only push source names down when the source contexts have distinct operation names; already-named nested requests can still be preserved.

                c.requests.iter().map(|req| {
                    let mut req = req.clone();
                    if req.operation_name.is_none() {
                        req.operation_name = c.operation_name.clone();
                    }

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/handler.rs:108

• The active-instance semantic convention and the updated diagnostics contract define this metric's attributes as server.address plus conditional server.port; db.system.name is currently explicitly deferred in the upstream convention. Emitting it here makes the standard metric use a different attribute schema than documented. Remove this attribute (and its test assertion) until the convention adds it.

        let mut attrs = Vec::with_capacity(3);
        attrs.push(KeyValue::new(
            attributes::ATTR_DB_SYSTEM_NAME,
            attributes::DB_SYSTEM_NAME_VALUE,
        ));

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/compaction.rs:149

• The operation name now separates compaction buckets, but compacted_run does not copy that name into the public CompactedRun rollup. Consequently PATCH read and replace runs with identical endpoint/status/context remain indistinguishable in serialized diagnostics, so consumers cannot tell which RU and latency statistics belong to which sub-operation—the decomposition this key is intended to preserve. Add an optional operation name to CompactedRun and populate it from the run's first request.

            operation_name: req.operation_name().map(str::to_string),

sdk/cosmos/azure_data_cosmos_driver/src/driver/cosmos_driver.rs:2813

• Populating the driver name here makes existing public documentation inaccurate: azure_data_cosmos/src/diagnostics/operation_context.rs:23-26 still says DiagnosticsContext does not capture the operation name, and diagnostics/logging/handler.rs:239-241 says production contexts do not carry one. Update those descriptions to explain that CosmosOperationContext supplies the caller-facing override/fallback, consistent with the new behavior.

        // Populate the canonical `db.operation.name` (e.g. `read_item`,
        // `query_items`) so the finalized diagnostics carry it in production —
        // feeding the emission layer's span/log attribute and the point-vs.-
        // non-point tail-sampling classification. `None` for operations without
        // a canonical name leaves it unset, matching prior behavior.
        if let Some(operation_name) = operation.db_operation_name() {
            diagnostics_builder.set_operation_name(operation_name);

[Copilot]

Pull request overview

Copilot reviewed 21 out of 21 changed files in this pull request and generated no new comments.

Suppressed comments (6)

sdk/cosmos/azure_data_cosmos_driver/src/driver/pipeline/patch_handler.rs:476

• For locally synthesized failures after a successful Read (missing ETag, body extraction/deserialization, patch evaluation, or serialization), err.diagnostics() is None, so sources contains only successful sub-operation contexts. This attaches diagnostics whose operation name is patch_item but whose status remains 200. The SDK then reports a successful status metric and DiagnosticsContext::is_failure() returns false, suppressing failure-triggered tracing/logging for an operation that returned an error. Stamp the aggregate's operation status from err.status() before attaching it, and cover one of these local-error paths with an is_failure()/effective-status assertion.

    let stamped = match sources.as_slice() {
        [] => return err,
        [only] => Arc::new(only.clone_with_operation_name(operation_name)),
        many => match DiagnosticsContext::aggregate_sub_operations(many) {
            Some(ctx) => Arc::new(ctx.with_operation_name(operation_name)),

sdk/cosmos/azure_data_cosmos_driver/src/models/cosmos_operation.rs:241

• FeedRange::is_logical_partition() also returns true for a partial hierarchical-partition-key prefix, but such a prefix covers multiple logical partitions (feed_range.rs:115-153; azure_data_cosmos/src/feed/query.rs:25-31). This therefore labels a cross-partition prefix read as read_all_items_of_logical_partition. Check that the partition key has all paths from the container's partition-key definition before selecting the singular logical-partition name.

                } else if self.targets_logical_partition() {
                    // `read_all_items(container, partition_key)` narrows the
                    // feed to one logical partition, which semconv names
                    // distinctly from the cross-partition read.
                    "read_all_items_of_logical_partition"

sdk/cosmos/azure_data_cosmos/src/diagnostics/metrics/attributes.rs:37

• This documentation still says the counter counts CosmosMetricsHandler instances, but the new implementation deliberately counts live CosmosClient registrations and allows one handler to serve multiple clients. Update the description so generated docs do not reintroduce the handler-lifetime model this PR replaces.

/// Optional up-down counter (instances): number of live
/// [`CosmosMetricsHandler`](super::CosmosMetricsHandler) instances (one per
/// instrumented client, under the intended one-handler-per-client registration).

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/compaction.rs:139

• Adding operation_name only to the private grouping key separates PATCH Read/Replace buckets internally, but CompactedRun does not expose that discriminator. In the exact case described here, the two public rollup rows can have identical region/endpoint/status/execution-context fields, so consumers cannot tell which RU and latency statistics belong to the Read versus Replace after compaction. Carry the operation name into CompactedRun (and update its documented grouping fields) so the decomposition remains observable.

    operation_name: Option<String>,

sdk/cosmos/azure_data_cosmos_driver/src/models/cosmos_operation.rs:213

• patch_read_item and patch_replace_item are not canonical Cosmos DB db.operation.name values. The OpenTelemetry Cosmos DB convention says a listed well-known value MUST be used when applicable, and lists read_item and replace_item; the patch_* variants are not listed. These child requests are actual Read/Replace operations, while their parent already identifies the caller operation as patch_item. Keep the standard names here and use a separate custom attribute if additional PATCH ownership is needed.

            (OperationType::Read, ResourceType::Document) if self.is_patch_sub_operation => {
                "patch_read_item"

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/diagnostics_context.rs:2079

• This populates a request-level name for every aggregation, including the dataflow retry path in CosmosResponse::with_aggregated_prior_diagnostics, where all source contexts and the aggregate have the same operation name. That contradicts the new public contract that RequestDiagnostics::operation_name() is None unless requests from different operations are combined, and unnecessarily changes serialized diagnostics for ordinary retries. Only copy the source name when it differs from the aggregate's inherited name; the later PATCH restamp will still preserve both sub-operation identities.

                c.requests.iter().map(|req| {
                    let mut req = req.clone();
                    if req.operation_name.is_none() {
                        req.operation_name = c.operation_name.clone();
                    }

[Copilot]

Pull request overview

Copilot reviewed 21 out of 21 changed files in this pull request and generated no new comments.

Suppressed comments (5)

sdk/cosmos/azure_data_cosmos_driver/src/models/cosmos_operation.rs:217

• patch_read_item and patch_replace_item are not Cosmos DB semantic-convention operation names. The current convention lists patch_item, read_item, and replace_item, and requires the respective well-known value whenever one applies. These internal requests are still a Read and Replace, so custom names make db.operation.name non-canonical and exclude them from tooling that groups the standard operations. Keep the root aggregate as patch_item, but label these attempts read_item / replace_item; their parent span already preserves that they belong to PATCH.

            (OperationType::Read, ResourceType::Document) if self.is_patch_sub_operation => {
                "patch_read_item"
            }
            (OperationType::Read, ResourceType::Document) => "read_item",
            (OperationType::Replace, ResourceType::Document) if self.is_patch_sub_operation => {
                "patch_replace_item"

sdk/cosmos/azure_data_cosmos/src/diagnostics/handler.rs:46

• Url::port() drops a scheme-default port, so a supported HTTP emulator endpoint such as http://localhost:80/ produces None here. Cosmos semconv treats 443 as the DBMS default, making port 80 conditionally required; this therefore merges emulator series that should carry server.port=80. Resolve the effective port and omit only Cosmos DB's default 443.

            server_port: endpoint.port(),

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/diagnostics_context.rs:2076

• This unconditionally copies each source context's name onto every request, but aggregate_sub_operations is also used for same-operation topology retries (models/cosmos_response.rs:197-207). Those non-PATCH contexts now redundantly serialize operation_name on every retained attempt, contradicting the new accessor docs that say the field is set only when multiple operations are aggregated. Only preserve a source name when it differs from the aggregate's inherited name; with_operation_name will still fill the final PATCH sub-operation when the aggregate is restamped.

                c.requests.iter().map(|req| {
                    let mut req = req.clone();
                    if req.operation_name.is_none() {
                        req.operation_name = c.operation_name.clone();
                    }

sdk/cosmos/azure_data_cosmos_driver/src/diagnostics/compaction.rs:149

• Adding operation_name only to the grouping key separates PATCH Read and Replace buckets internally, but CompactedRun does not carry or serialize that discriminator. When both sub-operations share region, endpoint, status, and execution context, diagnostics expose two otherwise indistinguishable rollup rows, so operators cannot tell which RU/duration statistics belong to the Read versus Replace. Add the issuing operation name to CompactedRun and populate it from the first request.

            endpoint: req.endpoint().to_string(),
            status: *req.status(),
            execution_context: req.execution_context(),
            operation_name: req.operation_name().map(str::to_string),

sdk/cosmos/azure_data_cosmos_driver/src/models/cosmos_operation.rs:482

• This public getter cannot return true for external callers: the only setter, as_patch_sub_operation, is crate-private, all public constructors initialize the flag to false, and operations are consumed by execution. It therefore adds an unusable public API (and changelog commitment) solely for crate-internal tests. Make the getter pub(crate) and remove it from the public changelog entry.

    pub fn is_patch_sub_operation(&self) -> bool {
        self.is_patch_sub_operation