Hi, I encountered the same issue as described in #97. After some debugging, I tried to call the ame service with BloomRPC GUI and default value was shown immediately. Some research lead me to -emit-defaults option which solves the issue for me. Although this is expected behaviour as explained in #97, it would be desirable to have -emit-defaults set by default and give the user the option to omit defaults if needed. This is obviously how BloomRPC and other clients/client libraries work.

Or is there anything against this approach?

Thanks!

Did this ever make it into a PR?

Nope, unfortunately I didn't get the chance to start.

Did this ever make it into a PR?

Let me try that!

It is indeed, but I included it since it may not always be obvious to do the reverse transformation. I will remove it if you think it's unnecessary.

Sounds good to me!

Adds typed errors used when looking up a message and finding an enum or vice versa.

Introduces the ability for grpcui to retry connecting to a server.

When the retry-max-attempts flag is supplied (and the value is greater than 0), the initial connection routine will attempt to retry connecting to the server, and exponentially back off the amount of time between connection attempts (from a minimum of 2 seconds to a maximum of 8 seconds).

This makes using grpcui as a sidecar to gRPC service development in docker-compose extremely easy.

docker-compose.yaml

version: "3.8"
services:
  grpc:
    build:
      context: .
      dockerfile: ./Dockerfile
      target: dev-runner
    env_file: .env
    volumes:
      - .:/usr/src/app
    ports:
      - 4045:4045
  ui:
    image: fullstorydev/grpcui:v1.1.0-3-gfe2bd93-dirty
    command: -plaintext -open-browser=false -retry-max-attempts=5 grpc:4045
    ports:
      - 8080:8080

Terminal output

~/Projects/testproj $ docker-compose up
Recreating testproj_ui_1 ... done
Starting testproj_grpc_1 ... done
Attaching to testproj_grpc_1, testproj_ui_1
ui_1    | Unable to reach host "grpc:4045"
ui_1    | Reconnecting in 2s
grpc_1  | [nodemon] 2.0.7
grpc_1  | [nodemon] to restart at any time, enter `rs`
grpc_1  | [nodemon] watching path(s): *.*
grpc_1  | [nodemon] watching extensions: py
grpc_1  | [nodemon] starting `python -m testproj`
grpc_1  | server starting on 0.0.0.0:4045
ui_1    | Retry attempt 1 of 5
ui_1    | gRPC Web UI available at http://0.0.0.0:8080/

This closes #101

Go is not my strength, but I’ll see if I can figure it out.

Sent from my iPhone

On Mar 1, 2021, at 6:47 PM, Joshua Humphries notifications@github.com wrote:

I'd be happy to review a PR in the vein of my suggestion above, if you're up for it, @troyswanson.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

I'm having the exact same issue. @danieleades, I would love to hear about what your solve for this was.

My solution was to wrap up that project and move onto another one...

Would be nice to see a resolution though, running grpcui as a sidecar to a development environment is a handy use-case

I'm having the exact same issue. @danieleades, I would love to hear about what your solve for this was.

go version
go version go1.13.8 linux/amd64

go get github.com/fullstorydev/grpcurl/...
go install github.com/fullstorydev/grpcurl/cmd/grpcurl
grpcurl -help
grpcurl: command not found

No error, no install, why?

P.S. use Ubuntu 20.04

  -authority string
        The authoritative name of the remote server. This value is passed as the
        value of the ":authority" pseudo-header in the HTTP/2 protocol. When TLS
        is used, this will also be used as the server name when verifying the
        server's certificate. It defaults to the address that is provided in the
        positional arguments.

I need to make TLS handshake with the domain lb.abc.com. And get contents from the VirtualServer with ServerName in Nginx set to test.abc.com. The TLS cert is for lb.abc.com, so the -authority didn't work.

Failed to dial target host "lb.abc.com:443": remote error: tls: handshake failure

Thank you, Josh. I discovered the flag -format-error which returns the gRPC error code in a way that I can use in my tests.

I humbly recommend that you document the 64+x offset somewhere other than the code; perhaps in the README or the -help because it is important to know if you are coding scripts. You could mention that format-error returns, for NOT-FOUND, the expected value as JSON, which is a very nice feature. Great tool!

{ "code": 5 }

I'm trying to get rid of the default host header but failed, the command I used grpcurl -v -H 'Host: test.abc.com' lb.abc.com:443 list.

Is this a bug or intended?