Azure / Azure/data-api-builder
[Bug]: Implement httpprotobuf as open telemetry protocol.
- Dominant language
- C#
- Stars
- 1.5k
- Forks
- 370
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 9
Description
### What happened?
While CLI implements the option to configure the protocol, the service implementation looks hard coded to GRPC. After spending many hours to get it to use httpprotobuf it looks like at a cold level its implemented to grpc.
Copilot validating:
> You’re right: service code is currently hard-coded to gRPC.
>
> Confirmed in these service paths (all set configure.Protocol = OtlpExportProtocol.Grpc; explicitly):
>
> src/Service/Program.cs (logging OTLP exporter)
> src/Service/Startup.cs (logging, metrics, tracing OTLP exporters)
> Meanwhile, config model/schema/CLI do expose exporter-protocol with grpc | httpprotobuf, but the service wiring does not read/use that value when creating exporters.
>
> So current state is:
>
> CLI/schema/config: supports httpprotobuf
> runtime exporter setup: effectively always gRPC
### Version
2.0.9
### What database are you using?
Azure SQL
### What hosting model are you using?
Local (including CLI)
### Which API approach are you accessing DAB through?
MCP
### Relevant log output
```Text
```
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Contributor guide
Research direction
Start in src/Service/Program.cs and src/Service/Startup.cs, where the logging, metrics, and tracing OTLP exporters are configured. Trace how exporter-protocol is loaded from the CLI/config model, then verify that each service exporter honors both grpc and httpprotobuf instead of forcing grpc; existing exporter tests, if present, should cover both values.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, grpc
- Domain
- backend, observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100