grpc-web icon indicating copy to clipboard operation
grpc-web copied to clipboard

'end' event not being sent for server-side streaming call

Open lily-es opened this issue 2 years ago • 3 comments

When performing a client call to a server-side streaming service, I never receive the 'end' event. The server implementation is in kotlin. Im using protoc-gen-grpc-web 1.4.2

This is my client code.

  const stream = getDataClient().generateBulkStatistics(request, metadata);
  stream
    .on('data', (response: ExampleResponse) => {
      console.log('Received data');
    })
    .on('error', (error: RpcError) => {
      console.log('Received error');
    })
    .on('end', () => {
      console.log('Received end');
    });

This is my protoc config

protoc \
  --js_out=import_style=commonjs,binary:$OUTPUT_FOLDER \
  --grpc-web_out=import_style=typescript,mode=grpcwebtext:$OUTPUT_FOLDER \

lily-es avatar Jan 20 '23 11:01 lily-es

@lily-es Thanks for the report!

When performing a client call to a server-side streaming service, I never receive the 'end' event. The server implementation is in kotlin. Im using protoc-gen-grpc-web 1.4.2

To confirm, I assume you observe this in a successful (non-error) streaming case, is that right?

I tried using the following TS example but unable to reproduce: https://github.com/grpc/grpc-web/tree/master/net/grpc/gateway/examples/echo/ts-example

I'm able to see the stream end signal received message printed in console: Screenshot 2023-02-07 at 4 41 26 PM

I'm wondering if it has something to do with your Kotlin server potentially? (We're using a Node server in our example.)

Also i assume you're using Envoy too, is that right?

Thanks!

sampajano avatar Feb 08 '23 00:02 sampajano

This problem exists if grpc requests is proxied via webpack dev server. This is a standard scenario during the development of frontend app, but any disconnects and backend's reboots don't emit 'error' and 'end' events in client. After building release bundle and running on server, all works correctly.

heggi avatar Feb 16 '23 00:02 heggi

Maybe this is related to #1363. For us, this is a PROD issue. The front proxy is nginx, with envoy behind it. However, the Browser detects and logs the issue, so I suspect it's an issue in this library, not a proxy misconfiguration

maja42 avatar Sep 19 '23 19:09 maja42