OTLP/HTTP receiver does not respond with google.rpc.Status on 400

[fbogsany]

Describe the bug
The OTLP/HTTP OTEP states:

Response body for all HTTP 4xx and HTTP 5xx responses MUST be a ProtoBuf-encoded Status message that describes the problem.

The collector's HTTP 400 response does not appear to contain a Protobuf-encoded google.rpc.Status message. The response body is Protobuf-encoded, but I can't tell what type it is.

Steps to reproduce
This was discovered while debugging #1344, so these steps only work with that bug present:

1. Setup Collector with otlp receiver.
2. Send OTLP/HTTP request with “Content-Encoding: gzip” request header and gzipped content.

What did you expect to see?
HTTP 400 response with a Protobuf-encoded google.rpc.Status message. This is specified as:

message Status {
  int32 code = 1;
  string message = 2;
  repeated google.protobuf.Any details = 3;
}

What did you see instead?
Debugging in Ruby, I saw:

(byebug) Google::Rpc::Status.decode(response.body)
*** Google::Protobuf::ParseError Exception: Error occurred during parsing: Invalid wire type
(byebug) response
#<Net::HTTPBadRequest 400 Bad Request readbody=true>
(byebug) response.body.b
"\n\x19proto: illegal wireType 7\x10\x03\x1A\x19proto: illegal wireType 7"

Picking this apart manually as a Protobuf message, we have:

0b1010 => field_number = 1, wire_type = 2 (length-encoded)
0x19 => length = 25
"proto: illegal wireType 7"
0b10000 => field_number = 2, wire_type = 0 (varint)
0x3
0b1110 => field_number = 3, wire_type = 2 (length-encoded)
0x19 => length = 25
"proto: illegal wireType 7"

which looks like a message type:

message Foo {
  string bar = 1;
  int32 baz = 2;
  string quux = 3;
}

What version did you use?
v0.5.0

What config did you use?

receivers:
  otlp:
    protocols:
      http:
exporters:
  jaeger:
    insecure: true
    endpoint: shopify-tracing.railgun:14250
extensions:
  zpages:
service:
  extensions: [zpages]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [jaeger]

Environment
OS: macOS Catalina 10.15.5 (19F101)
Compiler(if manually compiled): go version go1.13.3 darwin/amd64

Additional context
N/A

[fbogsany]

Digging into the gRPC Gateway code, it looks like this is actually an internal.Error type that aims to be compatible at the interface level with google.rpc.Status, but is not compatible at the wire level.

[fbogsany]

The fix is likely to pass a custom error handler to NewServeMux

opentelemetry-collector/receiver/otlpreceiver/otlp.go

Lines 65 to 67 in 2ba9cdc

	r.gatewayMux = gatewayruntime.NewServeMux(
	gatewayruntime.WithMarshalerOption("application/x-protobuf", &xProtobufMarshaler{}),
	)

using gatewayruntime.WithProtoErrorHandler.

[tigrannajaryan]

I believe this is now fixed and we have a test that verifies it:

opentelemetry-collector/receiver/otlpreceiver/otlp_test.go

Line 313 in 6c77fdb

name: "ProtoGzipUncompressed",

@fbogsany I have not verified the fix myself, but it appears correct. Closing this, please reopen if necessary.

[bogdandrutu]

I doubled check, this is solved only for errors in the gzip handler.