chore(opentelemetry-otlp): Make invalid combinations of transport & encoding unrepresentable #3229
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Really A Draft: Trying a different approach; please hold off on reviews!
Fixes #3082
This PR removes the ability to specify invalid combinations of transport (HTTP/gRPC) and encoding (JSON/Protobuf) by making the invalid combinations unrepresentable.
For completeness, I staged a separate branch that simply errors out when a user specifies an invalid combination. This has less impact on the API surface and is a smaller change, but doesn't prevent the user from specifying the invalid combinations. I prefer this variant here where we use the type system!
Changes
We do this by:
with_protocolfrom theWithExportConfigshared between both gRPC and HTTP exportersHttpEncodingProtocol, and supporting methods onWithHttpConfigto configure JSON or Protobuf encodingI wanted to draw a clear line between 'protocol' and 'encoding' as this feels like where the confusion has crept in, but the spec itself uses the term protocol to refer to both application layer protocol and body encoding.
Merge requirement checklist
CHANGELOG.mdfiles updated for non-trivial, user-facing changes