[feature request] Add integration/system/end-to-end tests for OTLP exporter

[martincostello]

Package

OpenTelemetry.Exporter.OpenTelemetryProtocol

Is your feature request related to a problem?

Via a long chain of changes, I discovered in the tests for one of my personal projects that v0.133.0 of the OpenTelemetry collector broke the ability to submit metrics from the OTLP exporter when http/protobuf was in use: grafana/docker-otel-lgtm#734

There was some discussion on whether or not the .NET exporter was compliant with the specification in open-telemetry/opentelemetry-collector#13727 (comment) and that this was the client's fault, but regardless the breaking change was not detected in any OpenTelemetry repository (or in Grafana's LGTM image's acceptance tests), indicating there's a level of missing test coverage to have found this before an end-user.

There was also similar change a few weeks ago that raised a question regarding higher-level test coverage regarding gRPC: #6449 (comment)

What is the expected behavior?

Add some integration/system/end-to-end tests (think black box, rather than get into a long discussion about test semantics) for the OTLP exporter that validate that OTLP signals for Logs, Metrics and Traces can be successfully submitted to an OpenTelemetry collector for:

• HTTP
• HTTP/protobuf
• gRPC

The collector should be something external to the repository (not a mock/hand-rolled) to give a level of confidence that real-world integrations will work and isolate us from potential assumptions in the implementation here being replicated on both ends of the test (think the two-unit-tests-no-integration-tests meme).

The tests should involve actual network communication, and not in-memory channels to verify that the wire protocol transmission is valid.

The tests do not need to be comprehensive, but give enough of a smoke test that core/critical functionality is working correctly.

Which alternative solutions or features have you considered?

None.

Additional context

Discussed in the SIG on 2nd September 2025.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[martincostello]

We do actually have some integration tests with the OpenTelemetry Collector, but if I use v0.133.0 which had the incompatibility that broke things, they pass.

For now will focus on why they didn't fail and fixing that instead. That will then give us a way to develop against fixing #6538 as that would require the original fix.

Then after that, can look at something that would have detected #6296.

[martincostello]

After some refactoring and extension in #6564, the existing OpenTelemetry Collector integration tests detect the regression in v0.133.0.

Once that PR is merged, I'll see if I can find a way to get the tests to also detect the issue from #6296, then we should be able to close this issue.

[martincostello]

I can't find an obvious way to validate that if TE=trailers isn't set that gRPC requests are rejected by the server. The OpenTelemetry Collector integration tests happily work without it being set.

Feels like any test I could quickly add wouldn't be of much value now that the header is there.