connectrpc / connect-es

The TypeScript implementation of Connect: Protobuf RPC that works.

Home Page:https://connectrpc.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Grpc-web lose connection after 60s for server-streaming calls

boan-anbo opened this issue · comments

Hi there!

With this GrpcWebTransport below, all server-streaming connections over http1 to different endpoints err after 60 seconds with either

unknown Connect error for CallbackClient

{"name":"ConnectError","rawMessage":"Load failed","code":2,"metadata":{},"details":[],"cause":{}}

or deadline_exceeded error on PromiseClient

Unhandled Promise Rejection: ConnectError: [deadline_exceeded] the operation timed out

	return createGrpcWebTransport({
		baseUrl: serverUrl,
		useBinaryFormat: true,
		interceptors: [logger],
		...opt,
	})

Within the 60 seconds, the connection receives messages without any issue.

Specifying transport defaultTimeoutMs or timeoutMs options on requests have effects only if the timeout is set to below 60 seconds.

If I set 10 seconds on timeoutMs, it timeouts after 10 seconds.

But if I set 100 seconds, it still timeouts after 60 seconds. 60 seconds seems to be the cap.

I don't see a pingIntervalMs transport options on Grpc-web trasport.

Connecting to the same streaming endpoints using other clients such as Postman does not have any issues without having to set client timeouts, so I assume the server side doesn't enforce a timeout.

"@connectrpc/connect" = "1.40"

Request headers

  • connect-es:
 {
"host": "127.0.0.1:23012", 
"x-user-agent": "connect-es/1.4.0", 
"accept": "*/*", 
"sec-fetch-site": "cross-site", 
"x-grpc-web": "1", 
"accept-language": "en-US,en;q=0.9", 
"accept-encoding": "identity,deflate,gzip", 
"sec-fetch-mode": "cors", 
"content-type": "application/grpc", 
"origin": "http://localhost:1420", 
"user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)", 
"referer": "http://localhost:1420/", 
"sec-fetch-dest": "empty", 
"connection": "keep-alive", 
"te": "trailers"
} 
  • other clients that do not have the issue:
 {
"grpc-accept-encoding": "identity,deflate,gzip", 
"accept-encoding": "identity", 
"user-agent": "grpc-node-js/1.8.10", 
"content-type": "application/grpc", 
"te": "trailers"}

I just realized this might not be connect-es issue but environment issue even though I haven't figured out who's dropping the connection. If so, please let me know and I'll close this. Thanks!