Parsing of grpc-web trailers is incorrect

See https://github.com/timostamm/protobuf-ts/blob/fefa69ba2bbad48aa6e28264b90b564b0f9846ec/packages/grpcweb-transport/src/grpc-web-format.ts#L303

And the docs for String#split()

Limit - A non-negative integer specifying a limit on the number of substrings to be included in the array. If provided, splits the string at each occurrence of the specified separator, but stops when limit entries have been placed in the array. Any leftover text is not included in the array at all.

This means that a response trailer that looks like this

grpc-status:9
grpc-message:Precondition failed for updated time (actual: 1633092892, expected: 1633092890)

Will result in an error being thrown like this: RpcError: Precondition failed for updated time (actual

The official grpc-web client parses the trailers with https://github.com/grpc/grpc-web/blob/3956560ad01b4af0a2a5c29c081f5bbd1424e85d/javascript/net/grpc/web/grpcwebclientreadablestream.js#L349-L358 where it finds the first index of :, everything before that is key and everything after is value.

This seems like an easy fix. I’ll try to put up a PR to address this over the weekend.

[jcready]

😅 I was working on it this weekend. I don’t quite have a PR ready for you yet, but here are a few things I’ve noticed already:

• Adding "sourceMap": true to tsconfig.test.json fixes the coverage report which made finding the areas missing coverage much easier.
• This first check seems unnecessary since the same check was already performed a few lines up. Also, at least in the case of parsing headers out of a normal Response, any duplicate entries (keys) will have their values .join(', ')-ed automatically so checking for any array is only necessary for parsing the trailers. https://github.com/timostamm/protobuf-ts/blob/12098410d02c9af3c8f9cf5e477cc4dd576ffbfa/packages/grpcweb-transport/src/grpc-web-format.ts#L275-L277
• As of yesterday I had the overall coverage of the grpcweb-transport package at:

  90.57% Statements 269/297
  75% Branches 147/196
  88.1% Functions 37/42
  90.31% Lines 261/289
  

• Most of the missing branches are for things like this which are time consuming but trivial to setup tests for https://github.com/timostamm/protobuf-ts/blob/12098410d02c9af3c8f9cf5e477cc4dd576ffbfa/packages/grpcweb-transport/src/grpc-web-transport.ts#L235-L249 Though obviously coverage doesn’t equate to meaningful tests so I’ve been trying to use the same tests that the official grpc-web client uses. For example this test looks like:

  it('handles multiple partial messages', async function () {
      const { frames, next } = getFrameRef();
      await next([0, 0, 0, 0, 2, 38]);
      assertFrames(frames, []); 
      await next([39, 128, 0, 0]);
      assertFrames(frames, [
          [D, [38, 39]],
      ]); 
      await next([0, 3, 40]);
      assertFrames(frames, [
          [D, [38, 39]],
      ]); 
      await next([41, 42], true);
      assertFrames(frames, [
          [D, [38, 39]],
          [T, [40, 41, 42]],
      ]);
  });
  

[timostamm]

Ha, so it doesn’t even do as I was arguing?

From the manual:

Response trailers are a very useful feature, but for simple unary calls, awaiting two promises is cumbersome. For this reason, the UnaryCall itself is awaitable, and will reject if an error status is received.

Apparently not, sorry about the confusion. gRPC clients for C# do behave like I argued, and @grpc/grpc-js does so as well, but it looks like I just pondered changing our implementation, and didn’t go forward with it. Changing the response promise to reject would definitely be a breaking change, so let’s hold on moving this.

FYI: Going through your PR at the moment (huge thanks in advance).