Repository navigation
bigtable getRows sometimes causes 'Transport Closed' error #2039
Description
Activity
@murgatroid99 this looks like a gRPC message. I'm assuming this happens because the channel closes due to inactivity, is there a way to specify a timeout? Or do we just need to create a new channel?
It is possible to set a timeout on a single call, but I don't think it will help here. You can also set the client to use HTTP2 ping to keep the TCP connection alive. This can be set up using the third argument to the Client constructor, which is a map whose keys are defined at https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L148.
You should be able to set the HTTP2 ping up using
"grpc.http2.min_time_between_pings_ms"and"grpc.http2.max_pings_without_data".@murgatroid99 awesome, thanks for the tips!
/cc @jmuk
@murgatroid99 I'm not having any luck getting ping to work, I've tried several combinations of configurations but I continue to get a transport closed error. Any thoughts on this?
A few of the other arguments may also be relevant. It may help to modify
"grpc.http2.keepalive_time"and"grpc.http2.keepalive_timeout", and also to set"grpc.http2.keepalive_permit_without_calls"to1.@callmehiphop is it possible for users to pass those grpc options in bigtable APIs? like,
require('@google-cloud/bigtable')({'grpc.http2.keepalive_time': time})?After discussing this with @ctiller, I realized that the solutions I recommended may not actually work. GFEs limit the number of HTTP2 pings they respond to per connection, so trying to repeatedly ping them may not actually accomplish anything.
gRPC can actually correct for TCP connections dying, but only if there are any pending gRPC events. This is why others have reported that repeatedly doing
SELECT 1fixes this problem. It should also be possible to achieve this by keeping a streaming call open forever, though that may be undesirable for other reasons.One alternative solution would be to downgrade to gRCP 1.1.1. That has some different internals that, among other things, should remove the requirement that there are pending events to detect TCP connection failure. Unfortunately, the changes in that version had to be reversed to fix #1946. I'm hoping to reintroduce them soon with the bugs ironed out.
@jmuk currently no, I don't believe we allow any pass throughs of grpc options.
@murgatroid99 that works! I rolled back to 1.1.1 (I think it was using 1.1.2) and the issue appears to have been resolved.
wait a min, 1.1.1 had another problem and that's why 1.1.2 was released, didn't it?
Yes. As I said, those changes in 1.1.1 were reversed in 1.1.2 to fix #1946. But the issue with 1.1.1 was mainly a problem on the previous version of the App Engine Node docker image. The issue with that docker image has also been fixed, so most users can use 1.1.1 safely. And most users who experience that problem with 1.1.1 can fix it by installing
netbaseunder Debian, or the equivalent package on other systems.Yeah, I was thinking about the description in the
package.json; we should keep 1.1.2 because of this issue. Of course people can manually modify their local installations.@jmuk so do we just want to wait for a new grpc release and instruct users reporting issues to do a local install of 1.1.1 in the meantime?
ping @jmuk @lukesneeringer
By the way, the fix for this problem will be in gRPC 1.2.0, which we expect to release very soon.
We have released gRPC 1.2.0.
Closing since grpc 1.2.0 is out.
- added 2 commits that reference this issue
on Feb 24, 2026 - added a commit that references this issue
on Mar 11, 2026 - added a commit that references this issue
on Mar 27, 2026
Error details:
This error is shown not all the time, but keeping some time idle the browser and accessing getRows throw this error. I am not able get any help regarding this. Can you please help to resolve this error?