shim/cli/query: should it really reconnect?

[pepyakin]

there is a subcommand query submit that submits a blob. There are potentially others

blobs/sugondat-shim/src/cli.rs

Lines 136 to 139 in 7c2731a

	// TODO: I envision several subcommands here. For example:
	// - query block <block_hash/number> — returns the information about a block and header.
	// - query blob <id> - returns the blob for a given key. The key here is the same sense as
	// described here https://github.com/thrumdev/blobs/issues/9#issuecomment-1814005570.

Those commands reuse the same infra that is used for dock implementations. Therefore it will for example try to establish connection until it succeeds.

The same would apply for query block. This command is useful for the same use-case as #108 (and may be even better tailored for the purpose, because it is already installed and doesn't require installing curl). The reconnection behavior is both useful and undesirable for that.

The behavior is somewhat useful for the healthcheck when it's meant to be used as part of initial setup. I.e. any service (e.g. demo-sovereign or demo-gm) can start after query block finally returned a block.

At the same time, it's somewhat harmful since if it's used for health detection of a running node then it would not reconnect. You may say, well, then maybe #108 + curl is better suited for that, and you may be right. However, even for the first use-case it doesn't fit well because if the shim is not compatible with the shim it will block until the issue is fixed (= forever in a static config like docker-compose).

[rphmeier]

It's very useful for a user not to be subject to spurious failures. I suggest that the default behavior be to reconnect, and we expose a --no-retry flag which fails fast and can be used in health-checking.

[pepyakin]

Good call, thanks for the suggestion.