<:robot:> A domain can declare `inbound.grpc` endpoints, pass `bench check`, build successfully, and produce a binary that doesn't serve them. Both entrypoint generators print a warning and skip the transport: ``` warning: domain "gkg-server" declares 1 gRPC endpoint(s); gRPC is not wired by this build and will be absent from the binary ``` That's `warn_unwired_transports` in the Go generator ([`cli/src/build/go.rs#L474`](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3205a6946ca01ceeba7124188f8e18c52c6ce578/cli/src/build/go.rs#L474)) and the same function in the Rust one ([`cli/src/build/rust.rs#L307`](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3205a6946ca01ceeba7124188f8e18c52c6ce578/cli/src/build/rust.rs#L307)). `bench build` exits 0 either way, so the only signal is a line on stderr. A developer who declared a gRPC service gets a running binary that answers nothing on that port. [`examples/grpc-service`](https://gitlab.com/gitlab-org/lab-bench/bench/-/tree/3205a6946ca01ceeba7124188f8e18c52c6ce578/examples/grpc-service) exists as a fixture for exactly this gap: a valid spec declaring `gitlab.inventory.v1.InventoryService` that builds into a binary without it. ## Context The chassis "owns the if": control decisions run before business logic, so a handler only ever sees vetted input. For HTTP that works today. gRPC bypasses it entirely by not existing, and the streaming case is where that matters most. GKG's `KnowledgeGraphService.ExecuteQuery` is a long-lived bidirectional stream (gap 14 in the [GKG example gap table](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3205a6946ca01ceeba7124188f8e18c52c6ce578/examples/gkg/README.md#gaps-found)), so a stream that opened without URT verification stays open, unvetted, for its whole lifetime. Per-call interceptors don't help there; the interceptor has to wrap the stream. Shutdown has the mirror problem. A long-lived stream that isn't drained on `SIGTERM` gets cut mid-response, and the client sees a transport error rather than a clean close. ## Upstream state: middleware in both languages, no server constructor in either Both LabKits provide gRPC middleware and expect the caller to build the server. Neither ships a gRPC equivalent of the HTTP server the chassis composes today, so this is the one inbound transport where "compose, never reimplement" needs a decision rather than an obvious answer. **Go.** [`v2/grpcserver`](https://gitlab.com/gitlab-org/labkit/-/tree/df307e038980743f2e50a83cf718b1de2b50f352/v2/grpcserver) is four files of interceptors. Its [`doc.go`](https://gitlab.com/gitlab-org/labkit/-/blob/df307e038980743f2e50a83cf718b1de2b50f352/v2/grpcserver/doc.go) scopes it precisely: "provides gRPC server interceptors that integrate with LabKit v2's correlation and logging packages," with the documented example having the caller construct `grpc.NewServer`. Compare [`v2/httpserver`](https://gitlab.com/gitlab-org/labkit/-/tree/df307e038980743f2e50a83cf718b1de2b50f352/v2/httpserver), which ships a server, router, health endpoints, recovery, and TLS across 18 files. **Rust.** [`labkit/src/grpc`](https://gitlab.com/gitlab-org/rust/labkit-rs/-/tree/main/labkit/src/grpc) provides Tower layers for Tonic: `GrpcCorrelationLayer`, `GrpcTraceLayer`, `GrpcAccessLogLayer`, and `GrpcMetricsLayer` behind the `otel` feature. Its [`mod.rs`](https://gitlab.com/gitlab-org/rust/labkit-rs/-/blob/main/labkit/src/grpc/mod.rs) documents the layer ordering and, again, has the caller build `tonic::transport::Server`. Two things make this easier than it first looks. `GrpcMetricsLayer` means the RED metrics requirement below is partly satisfied upstream on the Rust side. And Go's correlation interceptors already ship in both unary and streaming forms (`UnaryServerCorrelationInterceptor`, `StreamServerCorrelationInterceptor`), so the unary-plus-streaming split this issue needs is already the upstream pattern rather than something bench invents. Open question to settle first: does the generated entrypoint construct the gRPC server directly, composing LabKit's interceptors and layers, or do the LabKits grow a server constructor so both chassis compose one? Building it in bench is more code in two languages and risks drifting from `v2/httpserver`'s behavior; waiting adds an upstream dependency in two repos. Worth raising with the LabKit owners before writing code. ## Scope Wire gRPC in both generators: server construction, service registration from `GRPCEndpoint.service_name` and `proto_file`, and an interceptor chain covering unary and streaming calls. RED metrics ship with it rather than following later, because a transport without metrics is a second gap we'd have to come back for. Use OTel RPC semantic-convention names, which labkit-rs's `GrpcMetricsLayer` already emits. This deliberately differs from the `gitlab_*` names [bench#73](https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/73) settles for inbound HTTP. URT verification on streams is tracked in [bench#87](https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/87). Out of scope: the non-chassis parts of GKG gap 14, meaning the Workhorse `senddata` upgrade (GitLab-side ingress) and the mid-stream redaction callback (handler logic against an Outbound backend). ## Acceptance criteria - [ ] A bench built from the `examples/grpc-service` spec, with a handler implementing the service, produces a binary that serves `gitlab.inventory.v1.InventoryService` - [ ] The "absent from the binary" gRPC warning is gone from both the Go and Rust generators - [ ] The server-construction question above is settled and recorded in bench's design docs - [ ] Once the Go chassis ships, the LabKit server-constructor request ([draft](https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/65#note_3980120413)) is filed in `gitlab-org/labkit` and linked here - [ ] Interceptors wrap unary calls and streams; a stream cannot open without passing the same chain a unary call does - [ ] `SIGTERM` drains open streams before the process exits, rather than severing them - [ ] RED metrics are emitted for gRPC traffic with no developer action, using OTel RPC semantic-convention names (`rpc_server_duration_seconds`, `rpc_server_active_requests`) in both languages; the Rust side composes labkit-rs `GrpcMetricsLayer` unchanged and the Go side emits the same names - [ ] A test asserts a streaming call round-trips through the generated entrypoint Part of [DM-4: Phase 1 Inbound](https://gitlab.com/groups/gitlab-org/lab-bench/-/epics/4). </:robot:>