[OTLP] Fix NullReferenceException when no bucket boundaries configured for a view

[martincostello]

Fixes #6771

Changes

• Handle ExplicitBucketHistogramConfiguration.Boundaries being empty.
• Apply some IDE refactoring suggestions.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.66%. Comparing base (6ef3729) to head (0df65ce).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6773      +/-   ##
==========================================
- Coverage   86.69%   86.66%   -0.04%     
==========================================
  Files         262      262              
  Lines       12319    12320       +1     
==========================================
- Hits        10680    10677       -3     
- Misses       1639     1643       +4     

Flag	Coverage Δ
unittests-Project-Experimental	86.58% <100.00%> (-0.12%)	⬇️
unittests-Project-Stable	86.61% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ntation/Serializer/ProtobufOtlpMetricSerializer.cs	98.93% <100.00%> (+<0.01%)	⬆️
...trics/View/ExplicitBucketHistogramConfiguration.cs	83.33% <100.00%> (ø)

... and 3 files with indirect coverage changes

[Copilot]

Pull request overview

This PR fixes a NullReferenceException that occurs when serializing histogram metrics with empty bucket boundaries configured through a view. The fix adds a null check before attempting to serialize explicit bounds in the OTLP protobuf serializer.

• Added null safety check for ExplicitBounds before serialization
• Applied IDE-suggested refactoring to use modern C# collection expressions and simplified lambda syntax
• Added comprehensive test coverage for histogram serialization with both explicit boundaries and empty boundaries

Reviewed changes

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

Show a summary per file

File	Description
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/Serializer/ProtobufOtlpMetricSerializer.cs	Added null check for buckets.ExplicitBounds to prevent NullReferenceException; simplified lambda parameter syntax
src/OpenTelemetry/Metrics/View/ExplicitBucketHistogramConfiguration.cs	Refactored to use collection expression [.. value] instead of value.ToArray()
test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/Implementation/Serializer/ProtobufOtlpMetricSerializerTests.cs	Added tests for histogram serialization with explicit boundaries and no boundaries; refactored to extract common test logic
test/OpenTelemetry.Tests/Shared/EventSourceTestHelper.cs	Refactored to use collection expression [.. actualEvent.Payload!] instead of actualEvent.Payload!.ToArray()
test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/Implementation/Serializer/snapshots/ProtobufOtlpMetricSerializerTests.WriteMetricsData_Serializes_Metrics_With_No_Boundaries.verified.bin	New snapshot file for testing histogram with no boundaries
test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/Implementation/Serializer/snapshots/ProtobufOtlpMetricSerializerTests.WriteMetricsData_Serializes_Metrics_With_Explicit_Boundaries.verified.bin	New snapshot file for testing histogram with explicit boundaries
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/CHANGELOG.md	Documented the bug fix

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Kielek]

@rajkumar-rangaraj, @alanwest, should we consider this as good enough reason to make 1.15.0 release (or even cherry-picking it to 1.14.1)?

[rajkumar-rangaraj]

@rajkumar-rangaraj, @alanwest, should we consider this as good enough reason to make 1.15.0 release (or even cherry-picking it to 1.14.1)?

I suggest updating the patch version of OpenTelemetry.Exporter.OpenTelemetryProtocol to 1.14.1 while leaving the other packages as they are.

[Kielek]

@rajkumar-rangaraj, @alanwest, should we consider this as good enough reason to make 1.15.0 release (or even cherry-picking it to 1.14.1)?

I suggest updating the patch version of OpenTelemetry.Exporter.OpenTelemetryProtocol to 1.14.1 while leaving the other packages as they are.

It is against our release policy. All packages should be versioned together

[rajkumar-rangaraj]

It is against our release policy. All packages should be versioned together

Yes. Our policy requires all packages to be versioned together.

The current process was introduced to reduce maintenance overhead during an aggressive development phase and to enable automation. While it helped from an engineering efficiency standpoint, in the current situation it is causing customer confusion and resulting in unnecessary, unrelated package version bumps.

Based on customer feedback, this approach optimizes for our convenience but introduces real pain points for users. We should revisit the process and align it back with the release policy, even if that means slightly higher maintenance cost on our side.

[rajkumar-rangaraj]

@Kielek @alanwest @martincostello Like to hear your thoughts on #6773 (comment)

[martincostello]

As a user, I think I would prefer to just get a single package update for the OTLP exporter with any fixes/changes, rather than have everything be updated. I think it would be different if it were a root node (say OpenTelemetry.Api) rather than a leaf, where people might not explicitly reference the OTLP package and then not get the fix, but as it's a leaf it should be pay-for-play, so there should be a package reference to update.

Otherwise if we bump the version for everything, we'll be pushing out a new release and churn to users who don't use the OLTP exporter for no real reason (unless there's other unreleased changes they would benefit from).

[Kielek]

I agree with what you suggest, but it requires changes in the build pipeline.

In current state I would consider merging pr related to separation certificate check from mtls and makindg 1.15.0. There is some good stuff waiting for the release

[alanwest]

We discussed this a bit in today's meeting. The consensus was that we wait to push out 1.15.0 for all packages. We're making the assumption that this is not an urgent bug that needs to be released immediately and can wait a few weeks. If anyone feels otherwise, please chime in.

Generally though, we also discussed that if this were a more urgent bug then it would be ideal to have the option to release a patch version of only the affected package. We should consider making any necessary changes to the build pipeline to enable us to do this.