Panic in Relayer when Configuring Feegrant with Multiple Grant Results
GitHub Issue for Cosmos Relayer
Title
Panic in Relayer when Configuring Feegrant with Multiple Grant Results
Description
Encountering a panic in the Cosmos Relayer when attempting to configure feegrant using an existing allowance. This issue occurs when there is more than one page of results for the "query grants by granter" AllowancesByGranter RPC query.
Steps to Reproduce
- Set up a feegrant allowance for a grantee from a granter.
- Use the following command to configure the relayer:
rly chains configure feegrant basicallowance kujira kujira1vkje22mayn72r0a7kna6agv0sqm6k94ry9k6dd --grantees kujira1x9fxqdkg4rumkzrck8t3qnhm30jgfsx9ntcpas - The relayer panics with the following stack trace:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x23a9b16] goroutine 1 [running]: github.com/cosmos/relayer/v2/relayer/chains/cosmos.(*CosmosProvider).QueryFeegrantsByGranter(0xc0018e4900, {0xc001e9a1b0, 0x2d}, 0x0) /go/relayer/chains/cosmos/query.go:256 +0x276 github.com/cosmos/relayer/v2/relayer/chains/cosmos.(*CosmosProvider).GetValidBasicGrants(0xc0018e4900) /go/relayer/chains/cosmos/feegrant.go:36 +0x7a github.com/cosmos/relayer/v2/relayer/chains/cosmos.(*CosmosProvider).EnsureBasicGrants(0xc0018e4900, {0x348d1d8, 0xc000ca5c70}, {0x0, 0x0}, 0x2f2c2c8?) /go/relayer/chains/cosmos/feegrant.go:285 +0x328 github.com/cosmos/relayer/v2/cmd.feegrantConfigureBasicCmd.func1(0xc0011b9500, {0xc000c64400, 0x2, 0x2c730c4?}) /go/cmd/feegrant.go:143 +0x70e github.com/spf13/cobra.(*Command).execute(0xc0011b9500, {0xc000c643c0, 0x4, 0x4}) /root/go/pkg/mod/github.com/spf13/[email protected]/command.go:983 +0xabc github.com/spf13/cobra.(*Command).ExecuteC(0xc001178900) /root/go/pkg/mod/github.com/spf13/[email protected]/command.go:1115 +0x3ff github.com/spf13/cobra.(*Command).Execute(...) /root/go/pkg/mod/github.com/spf13/[email protected]/command.go:1039 github.com/spf13/cobra.(*Command).ExecuteContext(...) /root/go/pkg/mod/github.com/spf13/[email protected]/command.go:1032 github.com/cosmos/relayer/v2/cmd.Execute() /go/cmd/root.go:173 +0x13e main.main() /go/main.go:9 +0xf
Configuration
global:
api-listen-addr: :5183
timeout: 10s
memo: danb
light-cache-size: 20
chains:
kujira:
type: cosmos
value:
key: default
chain-id: kaiyo-1
rpc-addr: https://rpc.kujira.strange.love:443
account-prefix: kujira
keyring-backend: test
gas-adjustment: 1.2
gas-prices: 0.0034ukuji
min-gas-amount: 0
max-gas-amount: 0
debug: false
timeout: 20s
block-timeout: ""
output-format: json
sign-mode: direct
extra-codecs: []
coin-type: 118
signing-algorithm: ""
broadcast-mode: batch
min-loop-duration: 5s
extension-options: []
feegrants:
num_grantees: 1
granter: kujira1vkje22mayn72r0a7kna6agv0sqm6k94ry9k6dd
external_granter: true
grantees:
- kujira1x9fxqdkg4rumkzrck8t3qnhm30jgfsx9ntcpas
block_last_verified: 0
granteelastsignerindex: 0
neutron:
type: cosmos
value:
key: default
chain-id: neutron-1
rpc-addr: https://neutron-rpc.polkachu.com:443
account-prefix: neutron
keyring-backend: test
gas-adjustment: 1.2
gas-prices: 0.0053untrn
min-gas-amount: 0
max-gas-amount: 0
debug: false
timeout: 20s
block-timeout: ""
output-format: json
sign-mode: direct
extra-codecs: []
coin-type: 118
signing-algorithm: ""
broadcast-mode: batch
min-loop-duration: 5s
extension-options: []
feegrants: null
paths:
mainnet-kujira-neutron:
src:
chain-id: kaiyo-1
client-id: 07-tendermint-112
connection-id: connection-82
dst:
chain-id: neutron-1
client-id: 07-tendermint-2
connection-id: connection-2
src-channel-filter:
rule: allowlist
channel-list:
- channel-75
Additional Context
- Relayer version: 2.5.2
- Cosmos SDK: v0.50.4
- Go: go1.21.5 linux/amd64
Links
Documentation for Feegrant Configuration
Steps Taken
Successfully ran the update client with the configured feegrant:
rly tx update-clients mainnet-kujira-neutron
Transaction details:
- Transaction Hash on Kujira
- Fee payer:
kujira1x9fxqdkg4rumkzrck8t3qnhm30jgfsx9ntcpas
However, the relayer panics and might be preventing additional necessary configurations.
cc @KyleMoser
Good error report. This happens because there is bad logic in the paginator chains/cosmos/query.go:256 that's only triggered if there are multiple pages of grants for the granter. So for most users, this is never triggered.
The fix will involve removing the nil pointer dereference and writing an interchaintest case to prove the paginator works properly. Then @danbryan can test it again using the same exact command he used initially.
In the meantime, there is an easy workaround, which is to set block_last_verified: 0 to any block height greater than 0 in the config.
Setting block_last_verified > 0 seems to work as long as you make sure the grantees match the name of the key
eg
kujira:
type: cosmos
value:
key: default
feegrants:
num_grantees: 1
granter: kujira1vkje22mayn72r0a7kna6agv0sqm6k94ry9k6dd
external_granter: true
grantees:
# - kujira1x9fxqdkg4rumkzrck8t3qnhm30jgfsx9ntcpas #does not work
- default # does work
block_last_verified: 19171312
granteelastsignerindex: 0
This works https://finder.kujira.network/kaiyo-1/tx/8F9570F9B26F42EE6A47A2DEB0D619BF364BFC48956CF5D8E791C23B16406200
However, i think the stdout from the log message it has the wrong feepayer, it says
2024-05-25T16:01:10.625821Z info Successful transaction {"provider_type": "cosmos", "chain_id": "kaiyo-1", "gas_used": 336673, "fees": "1299ukuji", "fee_payer": "kujira1x9fxqdkg4rumkzrck8t3qnhm30jgfsx9ntcpas", "height": 19181348, "msg_types": ["/ibc.core.client.v1.MsgUpdateClient"], "tx_hash": "9F63A985A0DCA8BF1C138BC1434C1A0FA6385B624FBDBF81322C96915B1CF6A7"}
However, if you look at the tx it says
{
"key": "fee_payer",
"value": "kujira1vkje22mayn72r0a7kna6agv0sqm6k94ry9k6dd",
"index": true
}
Here are the changes i would suggest to make this tool more operator friendly.
1.) Don't require operators to set block_last_verified > 0
2.) allow the address to be used in the grantees
3.) update the stdout log to reflect the true fee payer
4.) have some documentation on how to update the config to use an external feegrant.
@KyleMoser any updates on this or anything we can do to further investigate and get a fix in place?