[ImamWahyudiz]

Description

Fixes #5892

otel.sdk.exporter.operation.duration and otel.sdk.metric_reader.collection.duration were created via create_otel_sdk_exporter_operation_duration and create_otel_sdk_metric_reader_collection_duration without explicit_bucket_boundaries_advisory=[].

Per the SDK self-observability specification for otel.sdk.exporter.operation.duration and otel.sdk.metric_reader.collection.duration, both duration histograms measure in seconds (s) and SHOULD be specified with explicit_bucket_boundaries_advisory=[] to avoid applying default millisecond bucket boundaries (0.0, 5.0, 10.0, ...).

This PR:

• Passes explicit_bucket_boundaries_advisory=[] in create_otel_sdk_exporter_operation_duration and create_otel_sdk_metric_reader_collection_duration.
• Adds unit tests verifying that the advisory is passed to meter.create_histogram().
• Verifies that reader metrics histogram data points use empty explicit bounds ().

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I am a human and not a bot
• I have run tox -e precommit
• I have run tox -e typecheck
• I have run the relevant tests and linting tox environments

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-11-07 13:19 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[knowprasad]

I reviewed the changes across \exporter/opentelemetry-exporter-otlp-common\ and \opentelemetry-sdk, and checked the duration histogram behavior against the SDK self-observability specification.

The fix is clean and aligns directly with the semantic conventions requirement for \otel.sdk.exporter.operation.duration\ and \otel.sdk.metric_reader.collection.duration. Both instruments record duration in seconds (\s), so omitting the explicit bucket advisory applied default millisecond buckets (0.0, 5.0, 10.0, ..., 10000.0). Passing \explicit_bucket_boundaries_advisory=[]\ ensures the histogram data points emit an empty boundary tuple ()\ unless overridden by a custom View.

A few specific observations from checking the diff:

1. Direct meter initialization: Calling \meter.create_histogram\ directly with \explicit_bucket_boundaries_advisory=[]\ in _exporter_metrics.py\ and _metric_reader_metrics.py\ is the right pragmatic solution here, since the upstream code generator for \opentelemetry.semconv._incubating.metrics.otel_metrics\ has not yet generated advisory parameter support in the helper factory functions.
2. Reader test assertion: In \ est_periodic_exporting_metric_reader.py, asserting \self.assertEqual(histogram.explicit_bounds, ())\ directly validates the runtime data point emitted during collection.
3. Suggested test parity for exporter metrics: In \ est_exporter_metrics.py, the test asserts the mock arguments on \meter.create_histogram. Adding a runtime check for \histogram.explicit_bounds == ()\ in \ est_proto_span_exporter.py\ (around line 685 where \otel.sdk.exporter.operation.duration\ data points are inspected) would give exporter duration the same end-to-end data point verification that reader metrics have.
4. Changelog: Verified that .changelog/5895.fixed\ matches the PR number and follows the expected convention.

Solid fix and good catch on self-observability metric compliance.

[ImamWahyudiz]

Thanks for the thorough review and suggestion, @knowprasad! I've updated est_proto_span_exporter.py in commit 1ef1b86 to assert metrics[0].data.data_points[0].explicit_bounds == (), providing the same end-to-end runtime data point verification for exporter duration metrics as well.