grpcui icon indicating copy to clipboard operation
grpcui copied to clipboard

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

Open micheljung opened this issue 1 year ago • 5 comments

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/

micheljung avatar Aug 18 '24 10:08 micheljung

I am having the same issue here.

nemith avatar Jan 10 '25 14:01 nemith

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.

jhump avatar Jan 10 '25 15:01 jhump

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?

nemith avatar Jan 16 '25 00:01 nemith

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.)

jhump avatar Jan 16 '25 14:01 jhump

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 https://github.com/fullstorydev/grpcui/issues/333#issuecomment-2595848452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACVJMGMDJKI2JKFQX7OZPL2K65PPAVCNFSM6AAAAABMWHCIKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJVHA2DQNBVGI. You are receiving this because you commented.Message ID: @.***>

nemith avatar Jan 16 '25 14:01 nemith