docs: Using agd to make queries and transactions

[dckc]

rendered:

• Using agd to make queries and transactions on dc-agd-query-tx branch

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	6eca109
Status:	✅  Deploy successful!
Preview URL:	https://7a3c7d14.documentation-7tp.pages.dev
Branch Preview URL:	https://dc-agd-query-tx.documentation-7tp.pages.dev

View logs

[LuqiPan]

So for me, yarn docker:bash gave some errors, I had to run yarn start:docker first for it to work. Likely because some time passed, or my laptop restarted since I went through Your First Agoric Dapp section

[LuqiPan]

You folks might've already thought about this but would it be possible to create a separate repo that contains all of the docker compose stuff and make all other Dapp sample repos include/reference the same docker compose repo?

[dckc]

So for me, yarn docker:bash gave some errors, I had to run yarn start:docker first for it to work.

Were the errors / diagnostics straightforward to understand? You evidently figured out how to proceed. It's not practical to make yarn docker:bash work without yarn start:docker first, but if the diagnostics aren't clear, we could perhaps address that.

[dckc]

re separate repo: it's worth considering

• reusable repo for docker compose materials #902

[LuqiPan]

Re errors / diagnostics, I was getting a pretty generic error

Error: post failed: Post "http://localhost:26657": dial tcp 127.0.0.1:26657: connect: connection refused

And I figured it out by backtracking my way through Your First Agoric Dapp section and run the docker related command preceding yarn docker:bash

[dckc]

you got that error in response to yarn docker:bash? that seems unlikely. Perhaps in response to agd status? That's possible, but it would mean you have agd available outside the container.

[LuqiPan]

suggestion

Pipe the output to jq for readability? I tested in the docker container and it does have jq installed already

[dckc]

Are you suggesting that we inform our readers about the jq technique?

Or that the output currently in the docs is less readable than it should be?

[LuqiPan]

Yeah I'm suggesting we inform our readers about the jq technique, because the output of this command is a json blob without any formatting or whitespaces in between.

[LuqiPan]

ditto

[dckc]

seems like once is enough to teach the technique.

[LuqiPan]

just for my own curiosity

Why is it? Was it because we need to specify port 443 for gRPC to work?

[dckc]

I don't know why cosmos SDK requires it. I just know that it does.
@JimLarson ? @michaelfig ? Do you know? Should we open an issue?

[gibson042]

Handling for the --node $rpcUri option is client, err := NewClientFromNode(rpcURI), where NewClientFromNode(nodeURI string) returns rpchttp.New(nodeURI, "/websocket") and rpchttp is now cometbft rpc/client/http/http.go but was formerly tendermint rpc/client/http/http.go. Both use url.Parse to parse the input string into a parsedUrl struct "u" and return an http.Client with a Transport whose Dial function is implemented to return net.Dial(protocol, u.GetDialAddress()) [CometBFT, Tendermint], where GetDialAddress() for a URL destination [as opposed to the path of a Unix domain socket] returns the parsed Host (causing failure in the absence of a port because net.Dial is low-level and requires that).

Bottom line, this could easily be fixed by updating func (u parsedURL) GetDialAddress() to pay attention to URL Scheme, e.g.

 // GetDialAddress returns the endpoint to dial for the parsed URL.
 func (u parsedURL) GetDialAddress() string {
-	// if it's not a unix socket we return the host, example: localhost:443
+	// if it's not a unix socket we return the host with port, example: localhost:443
 	if !u.isUnixSocket {
+		hasPort, err := regexp.MatchString(`:[0-9]+$`, u.Host)
+		if err == nil && !hasPort {
+			if u.Scheme == protoHTTP || u.Scheme == protoWS {
+				return u.Host + `:80`
+			} else if u.Scheme == protoHTTPS || u.scheme == protoWSS {
+				return u.Host + `:443`
+			}
+		}
 		return u.Host
 	}
 	// otherwise we return the path of the unix socket, ex /tmp/socket
 	return u.GetHostWithPath()
 }

I think it makes sense to report upstream.

[gibson042]

cometbft/cometbft#1902
tendermint/tendermint#5407

[JimLarson]

I'm guessing that since they're using the URL format, they don't want to mess with the assumption that 80 is the implicit port number. Since they don't want to squat on the webserver's favorite port, it would make sense to pick a different standard port number, then make it explicit in the node argument.

[gibson042]

Update: cometbft no longer requires an explicit port for http/https or ws/wss URLs.