Call stuck connecting when server is initially unavailable, but becomes available later

Problem description

I have a (C#) grpc server and (grpc-js) client, which I start simultaneously and connect them over loopback (127.0.0.1). Usually the server becomes ready after the client, thus client will often observe nothing listening on a port initially.

Prior to grpc-js 0.7.5 it worked all quite fine, client and some initial calls that I start waited for the server to get ready and connected silently. Apparently 0.7.5 introduced some fixes that made calls fail-fast when client is not connected, so I modified code passing waitForReady:true in metadata.

Unfortunately, this didn’t bring the previous behavior. Now the client / calls are stuck and never connect successfully.

Reproduction steps

1. clone https://github.com/kskalski/snippets/tree/master/GrpcJsElectronSharp
2. cd GrpcJsElectronSharp && ./build.sh (adjust paths as needed in the script)
3. run ./Server.exe
4. run ./Client.exe
5. observe server receiving messages whenever Client’s window is minimized (handler triggering message send)
6. stop Client and Server
7. run ./Client.exe
8. run ./Server.exe
9. observe server no longer receives messages when Client’s window is minimized (the calls are stuck on connecting)

Environment

• OS name, version and architecture: Windows 10, x64
• Node version: Electron 8.3.0 (Node 12)
• Node installation method Electron
• If applicable, compiler version .NET 4.6
• Package name and version 0.7.5 (it happens also on 1.0.3, but I was able to backtrack that the problem appeared between 0.7.4 and 0.7.5)

Additional context

I poked around a bit and it seems that there is TRANSIENT_FAILURE in channel.js (this piece of code executed):

case picker_1.PickResultType.TRANSIENT_FAILURE:
                if (callMetadata.getOptions().waitForReady) {
                    this.pickQueue.push({ callStream, callMetadata });

but nothing happens afterwards, there is never completion or other result of re-connection attempt

[murgatroid99]

grpc 1.24.2 is the other implementation. It shares no code with the library that has the bug that this issue is about. So, that sounds similar but it is definitely not the same bug.

[sidcool1234]

I am on the version ^1.1.7. The bug is showing up still. google pub sub version is 1.1.6.