-connect-fail-fast=false doesn't work

[micheljung]

Neither on Windows 11 nor with the Docker image.

grpcui --version
grpcui v1.4.1

grpcui --open-browser=false -plaintext -connect-fail-fast=false -connect-timeout=1 127.0.0.1:9000
Failed to dial target host "127.0.0.1:9000": dial tcp 127.0.0.1:9000: connectex: No connection could be made because the target machine actively refused it.

<program exits>

As soon as the gRPC server is running:

grpcui --open-browser=false -plaintext -connect-fail-fast=false -connect-timeout=1 127.0.0.1:9000
gRPC Web UI available at http://127.0.0.1:13540/

[nemith]

I am having the same issue here.

[jhump]

When that flag is true (the default), connection errors will cause the UI to bail immediately and report the error. When it is false, connections will be retried (with exponential backoff) up until the timeout is reached.

So I think the issue is the -connect-timeout=1 flag, which means even when it retries instead of failing fast, it still fails because it will only wait one second for the connection to be established.

You should set the timeout to the maximum amount of time to wait for a connection. When used with multiple docker images, this should be the maximum time for the server container to actually start and begin serving, which is probably on the order of single digit minutes, not single digit seconds.

[nemith]

It would be nice to not have a timeout at all if you are really deploying as a side car. I tried a negative number but it wasn't supported.

Would infinity timeout be out of the question?

[jhump]

You can set it to an absurdly large number, like 2000000000 (which is ~63 years), and it will be effectively infinite.

Looks like there is currently an overflow risk if you set the value too high though. (Should be fixed in #360.)

[nemith]

that works for one of type projects but working in larger teams some animality large value is more confusing that something that is clear about the expectations. This is fine for my use case where it’s local development and it may be a while before I get the compile to not be broke and start again.

…

On Thu, Jan 16, 2025, at 7:17 AM, Joshua Humphries wrote: You can set it to an absurdly large number, like 2000000000 (which is ~63 years), and it will be effectively infinite. Looks like there is currently an overflow risk if you set the value *too high* though. — Reply to this email directly, view it on GitHub <#333 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVJMGMDJKI2JKFQX7OZPL2K65PPAVCNFSM6AAAAABMWHCIKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJVHA2DQNBVGI>. You are receiving this because you commented.Message ID: ***@***.***>