grpc_json_transcoder: unknown JSON body fields are dropped silently with no validation option — is an opt-in strict mode or a surfaced drop in scope?

[cleitonaugusto]

Hi, and thanks for the transcoder filter — this is a question about validation scope and visibility, not a bug report.

When a JSON request to envoy.filters.http.grpc_json_transcoder carries a field the target protobuf message does not define, the filter drops it while transcoding to protobuf and forwards the RPC. The client receives 200 OK and the upstream receives a well-formed message; neither side is told a field was discarded.

Minimal reproduction

Service with a message that names two fields:

message Command {
  string action = 1;
  int32  amount = 2;
}
service Gateway {
  rpc Send(Command) returns (Ack) {
    option (google.api.http) = { post: "/v1/send" body: "*" };
  }
}

Transcoder in front of a gRPC upstream. Then:

POST /v1/send  {"action":"transfer","amount":1,"auth":"...."}

The upstream receives only action and amount; the auth field is gone, and the response is 200 OK. Measured on Envoy 1.31.10 (envoyproxy/envoy:v1.31-latest).

The part worth asking about

GrpcJsonTranscoder.request_validation_options offers three switches —
reject_unknown_method, reject_unknown_query_parameters and
reject_binding_body_field_collisions — and none concerns an unknown field in the
JSON request body. I enabled reject_unknown_method and
reject_unknown_query_parameters together and the request carrying an unknown body
field still returned 200 OK with the field dropped. So, unlike grpc-gateway and
connect-go, there appears to be no configuration on this filter that rejects it.

Questions

1. Is the absence of a body-field validation option deliberate — i.e. is silently dropping unknown JSON body fields considered the correct behaviour for the proto3 JSON mapping here?
2. Would an opt-in strict mode be in scope — for example a reject_unknown_body_fields under request_validation_options, mirroring the existing method/query switches?
3. Failing that, would surfacing the drop (a filter metric or an access-log field for discarded body fields) be in scope, so an operator can notice it without a config option?

For context: grpc-gateway (grpc-ecosystem/grpc-gateway#7220) and connect-go (connectrpc/connect-go#954), which apply the same JSON mapping, both drop by default too, but each exposes a way to reject (a marshaler option and a replacement codec respectively). Envoy is the one stack among the three where I could find no such control, which is why I am asking whether an opt-in or a visibility signal is in scope rather than reporting a defect. Happy to share the reproduction if useful.