You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 21, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 21, 2026. It is now read-only.
How do I get on the latest version of @grpc/grpc-js? #789
Over the past few weeks there were a few bad releases of @grpc/grpc-js that went out the door, and effect the behavior of @google-cloud/pubsub, and other libraries that rely on grpc.
There is now a version of @grpc/grpc-js available, 0.6.9, which has addressed a variety of stability issues.
Getting on the new version
in your project that uses @google-cloud/pubsub (@google-cloud/logging, etc), delete package-lock.json.
delete your node_modules/ folder, so that you will receive a fresh install.
npm install.
npm ls 👈 look at this tree, it should indicate that you are on up-to-date versions of @grpc/grpc-js, if not let us know and we can help.
What if I don't want to remove my package-lock.json?
As an alternative, you may also be able to run npm update @grpc/grpc-js, afterwards run npm ls, and confirm that all copies have been updated appropriately.
@npomfret correct, we are in the process of updating everything explicitly across all our libraries, so it would be good to check after the update, with npm ls to make sure you do have up-to-date dependencies.
@bcoe Given the issues with 0.6.9 (which completely breaks down for me) in grpc/grpc-node#1085, what's the most stable version from what you've seen so far? 0.5.4 seemed decent for me, curious if a more recent one is worth a shot.
@bcoe The weird thing is our issues are manifesting primarily as a memory leak (although too many sockets/connection could definitely be part of the story).
Basically we are running a system that is doing a lout of outbound HTTP requests and posting parsed results through PubSub, and the recent versions result in a lot of timeouts for those outbound requests (not the ones to PubSub). I did try running the C++ grpc bindings in a testing environment for ~2.5 hours, which unfortunately also resulted in a significant increase in request errors - although not at all on the scale of what 0.6.9 gave us.
Reverting to the following versions is the least problematic so far, and I have no satisfactory explanation to why. Memory and CPU usage does not explain this for when we're using grpc.
I'm going to go ahead and close this since we haven't needed to manually bump anyone to newer grpc-js lately, but please feel free to comment and/or re-open if needed.
Activity
npomfret commentedon Oct 22, 2019
@bcoe so there are no code changes? I merely bring in the latest changes?
bcoe commentedon Oct 22, 2019
@npomfret correct, we are in the process of updating everything explicitly across all our libraries, so it would be good to check after the update, with
npm lsto make sure you do have up-to-date dependencies.Legogris commentedon Oct 29, 2019
@bcoe Given the issues with
0.6.9(which completely breaks down for me) in grpc/grpc-node#1085, what's the most stable version from what you've seen so far? 0.5.4 seemed decent for me, curious if a more recent one is worth a shot.bcoe commentedon Oct 29, 2019
@Legogris if you are running into the memory leak described in 1085, I recommend potentially running the C++ grpc version for the time being:
https://github.com/googleapis/nodejs-pubsub#running-grpc-c-bindings
Once tested, we will work with the gRPC team to get a patch for the memory leak described in grpc/grpc-node#1085 out ASAP.
Legogris commentedon Oct 29, 2019
@bcoe The weird thing is our issues are manifesting primarily as a memory leak (although too many sockets/connection could definitely be part of the story).
Basically we are running a system that is doing a lout of outbound HTTP requests and posting parsed results through PubSub, and the recent versions result in a lot of timeouts for those outbound requests (not the ones to PubSub). I did try running the C++
grpcbindings in a testing environment for ~2.5 hours, which unfortunately also resulted in a significant increase in request errors - although not at all on the scale of what0.6.9gave us.Reverting to the following versions is the least problematic so far, and I have no satisfactory explanation to why. Memory and CPU usage does not explain this for when we're using
grpc.Perhaps part of the issue originates from changes in
@google-cloud/pubsubitself, or some other transitive dependency.Will be keen to give the next version a spin.
Thank you for the diligence and following up.
bcoe commentedon Oct 29, 2019
@Legogris it might be worth bringing the conversation over to #788, because this conversation is related specifically to memory issues.
I'm sharing your updates with internal folks, and we're in the process of discussing what might be causing these memory issues.
If possible could you share some sample code demonstrating how you initialize your client?
feywind commentedon May 5, 2020
I'm going to go ahead and close this since we haven't needed to manually bump anyone to newer grpc-js lately, but please feel free to comment and/or re-open if needed.