hermes
hermes copied to clipboard
Parameterize ics31/icq response type url
Summary
Currently the response type url of an interchain-query is hard coded to /stride.interchainquery.v1.MsgSubmitQueryResponse
in https://github.com/informalsystems/hermes/blob/d9296b550d1142b2d10a8af0e3a18661379b38ce/crates/relayer-types/src/applications/ics31_icq/response.rs#L10C29-L10C78
Problem Definition
Which results in anyone trying to use icq from a chain that isn't Stride to fail with:
estimate_gas: failed to simulate tx. propagating error to caller: gRPC call `send_tx_simulate` failed with status: status: Unknown, message: "unable to resolve type URL /stride.interchainquery.v1.MsgSubmitQueryResponse: tx parse error [cosmos/[email protected]/x/auth/tx/decoder.go:42] With gas wanted: '0' and gas used: '6666' ", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "x-cosmos-block-height": "53"} }
Proposal
My suggestion is to add this as parameter to the config.toml
file.
If someone could suggest the right spot, we'd be happy to take a stab at submitting a PR with this type url constant turned into a parameter.
Acceptance Criteria
Forking hermes and modifying a constant isn't required to be able to receive MsgSubmitQueryResponse
For Admin Use
- [ ] Not duplicate issue
- [ ] Appropriate labels applied
- [ ] Appropriate milestone (priority) applied
- [ ] Appropriate contributors tagged
- [ ] Contributor assigned/self-assigned
Hi @george-aj thanks for opening this issue. What is the chain or chains which are triggering the failure you posted ?
Hi @ljoss17, I'm running two chains locally, a new one and a local version of Juno v15.0.0 I get this error when sending an icq query from the new one to Juno.
Is it correct that the chain emitting the ICQ uses other protos than these ones https://github.com/Stride-Labs/stride/tree/v11.0.0/proto/stride/interchainquery/v1 ? If so, would it be possible to see what protos it uses ?
So it has those protos, but it's proto package name was changed and as a result all of the type urls.
I should add that I succesfully forked hermes, modified the type url constant to the local chains ICQ proto type url and all is well.
Moving this issue to a blocked state as we've determined that the best way to fix this issue is to ultimately have the ecosystem consolidate on a single instance of the ICQ proto files, rather than having multiple implementations, which may or may not adhere to the ICS31 specification, floating around.
If more teams need this sort of parameterization in the Hermes config, we can consider revisiting adding it that functionality in the Hermes config, but for the time being we'd prefer to not endorse that route.
Hi Sean, I agree the ecosystem should settle on single proto for this purposes, but who knows when that will be. I figured adding a parameter until such time was low hanging fruit so the ICQ relaying functionality was actually usable.