silent fails on invalid deserialization

[QuaereMe]

On 1.2.0, generating typescript bindings.

tl;dr: when envoy returns identical payloads for grpcwebtext and grpcweb modes, the grpc-web TS bindings return an unhelpful null response and no error for the invalid payload.

Background:
I'm generating the bookstore proto demo with typescript bindings so that I can hit a espv2 endpoint in GCP with an Angular application. If I generate with grpcwebtext using this...

protoc -I=${dir} -I=../proto_deps/protobuf/src ../bookstore.proto --js_out=import_style=commonjs,binary:grpc_output_dir --grpc-web_out=import_style=typescript,mode=grpcwebtext:grpc_output_dir

...then the callback response populates as null. By inspecting the callstack in chrome devtools, (to the wrapFn call in zone-evergreen.js) I can see that the server is, in fact, returning a serialized response. If I use grpcweb mode instead, the message deserializes correctly and populates just fine.*

I think there are two bugs here. See, I'm getting an identical response payload from the espv2 envoy-based proxy (which is supposed to have grpc-web support built-in from the included envoy distribution), regardless of whether I'm using the base64-encoded grpcwebtext or binary grpcweb modes. But I'm filing this particular bug because I'd like to see an error thrown if deserialization fails. (Unless I'm misunderstanding how the formats work...)

Fwiw, the default "listshelves" method from that version of envoy returns a payload of AAAAABoKCwgBEgdGaWN0aW9uCgsIAhI on requests with both content-types, and I think that's incorrect, but in any case I'd like to see the grpc-web TS bindings complain a bit more when that happens rather than just returning a null response with no error.

*The proto_deps path I have in there is just a clone of protocolbuffers/protobuf because I'm lazy and the bookstore protos from gcp demo repo complains when it can't find the google empty proto.

[stanley-cheung]

@QuaereMe Thanks for the report. Sorry for the delay - am looking into this now. Just want to confirm one thing first: AAAAABoKCwgBEgdGaWN0aW9uCgsIAhI is exactly the payload you received? Nothing more, nothing less?

[QuaereMe]

Yes, that is exactly the payload on both requests. Thanks for looking into this! I'll try to test against master this weekend, and will leave this closed unless it still fails.