Write e2e tests for channel upgradability

[crodriguezvega]

Some tests that we could write. Each can be done in a separate PR.

The start situation for all these tests is: 2 chains with an opened transfer channel that would like to upgrade the channel to use fee middleware. Unless in the crossing hello scenario, chain A executes ChanUpgradeInit and chain B ChanUpgradeTry.

Tasks

Preview Give feedback

1. Successful e2e test where the channel is upgraded and fee middleware is enabled #5357
   channel-upgradability e2e +2
   
2. Successful test with crossing hello scenario #5393
   channel-upgradability e2e +2
   
3. e2e: ordered ICA channel can be closed after upgrading to wire up fee middleware and a packet timeout afterwards #5538
   channel-upgradability e2e +2
   
4. Unsuccessful test where both chains move to FLUSHING but the relayer takes too long to clear the inflight packets (of chain B, for example). An error receipt is written and both chains restore the channel to its initial state. (tested manually)
5. e2e test where ChanUpgradeAck fails on chain A because counterparty-specified timeout has elapsed #5531
   channel-upgradability e2e +2
   
6. Unsuccessful test where chain B during ChanUpgradeConfirm has exceeded the counterparty-specified timeout. An error receipt is written and both chains restore the channel to its initial state.
7. Unsuccessful test where governance of chain A cancels the upgrade after chain A executes ChanUpgradeAck. (tested manually)

[expertdicer]

Hello guys, can I take the issues? TYSM

[crodriguezvega]

Hello guys, can I take the issues? TYSM

Thank you very much, @expertdicer! We are trying to get one happy path test passing first, but we're having some issues in our integration with hermes, as soon as that it solved I think it will be easier to tackle the other tests, so I can ping you back when that happens.

[crodriguezvega]

Hermes was lacking support for channel upgrade cancel, so I implemented that in this PR, so that I could do the following manual tests:

Successful test with crossing hello scenario

It seems like the relayer submits channel upgrade try to both chains, but then the upgrade doesn't continue any further.

# create channel between chain1 and chain2
> hermes --config config.toml create channel --a-chain chain1 \
--b-chain chain2 \
--a-port transfer \
--b-port transfer \
--new-client-connection 

> hermes --config config.toml start

# submit a vote proposal on chain1 to do channel upgrade init
> simd tx gov submit-proposal ./proposal_upgrade_channel.json --from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

> simd tx gov vote 1 yes \
--from validator \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# submit a vote proposal on chain2 to do channel upgrade init
> simd tx gov submit-proposal ./proposal_upgrade_channel.json --from cosmos14py05zhnktwjuj4l537va8mre3j7qsx4frahew \
--chain-id chain2 \
--keyring-backend test \
--home ../../gm/chain2 \
--node http://localhost:27010

> simd tx gov vote 1 yes \
--from validator \
--chain-id chain2 \
--keyring-backend test \
--home ../../gm/chain2 \
--node http://localhost:27010

Unsuccessful test where both chains move to FLUSHING but the relayer takes too long to clear the inflight packets (of chain B, for example). An error receipt is written and both chains restore the channel to its initial state.

I couldn't complete the test because hermes seems to relay only packets if the channel state is OPEN or CLOSED, and not FLUSHING.

# create channel between chain1 and chain2
> hermes --config config.toml create channel --a-chain chain1 \
--b-chain chain2 \
--a-port transfer \
--b-port transfer \
--new-client-connection 

# submit a vote proposal on chain1 to do channel upgrade init
> simd tx gov submit-proposal ./proposal_upgrade_channel.json --from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

> simd tx gov vote 1 yes \
--from validator \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# send transfer packet from chain1 to chain2
> simd tx ibc-transfer transfer transfer channel-0 cosmos14py05zhnktwjuj4l537va8mre3j7qsx4frahew  100samoleans \
--from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# do channel upgrade try on chain2
> hermes --config config.toml tx chan-upgrade-try \
--dst-chain chain2 \
--src-chain chain1 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

# do channel upgrade ack on chain1
> hermes --config config.toml tx chan-upgrade-ack \
--dst-chain chain1 \
--src-chain chain2 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

# wait enough time for upgrade timeout to pass
# then try to relay transfer packet from chain1 to chain2
# this will cause the upgrade to abort on acknowledge packet on chain1
> hermes --config config.toml tx packet-recv \
--dst-chain chain2 \
--src-chain chain1 \
--src-port transfer \
--src-channel channel-0

ERROR channel channel-0 on chain chain1 not in open or close state when packets and timeouts can be relayed

> hermes --config config.toml tx packet-ack \
--dst-chain chain1 \
--src-chain chain2 \
--src-port transfer \
--src-channel channel-0

# do channel upgrade cancel on chain2 and restore channel
> hermes --config config.toml tx chan-upgrade-cancel \
--dst-chain chain2 \
--src-chain chain1 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

where proposal_upgrade_channel.json contains:

{
  "title": "Channel upgrade init",
  "summary": "Channel upgrade init",
  "messages": [
    {
      "@type": "/ibc.core.channel.v1.MsgChannelUpgradeInit",
      "signer": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
      "port_id": "transfer",
      "channel_id": "channel-0",
      "fields": {
        "ordering": "ORDER_UNORDERED",
        "connection_hops": ["connection-0"],
        "version": "{\"fee_version\":\"ics29-1\",\"app_version\":\"ics20-1\"}"
      }
    }
  ],
  "metadata": "AQ==",
  "deposit": "100005stake"
}

Unsuccessful test where chain A during ChanUpgradeAck has exceeded the counterparty-specified timeout. An error receipt is written and both chains restore the channel to its initial state.

I tested this scenario manually with the following commands chain1 aborts the upgrade on ack and then I was able to relay the cancellation to chain2 and cancel as well the upgrade on its side. These are the commands I used:

# create channel between chain1 and chain2
> hermes --config config.toml create channel --a-chain chain1 \
--b-chain chain2 \
--a-port transfer \
--b-port transfer \
--new-client-connection 

# submit a vote proposal on chain2 to update channel params with shorter upgrade timeout (5s)
> simd tx gov submit-proposal ./proposal_update_params.json --from cosmos14py05zhnktwjuj4l537va8mre3j7qsx4frahew \
--chain-id chain2 \
--keyring-backend test \
--home ../../gm/chain2 \
--node http://localhost:27010

> simd tx gov vote 1 yes \
--from validator \
--chain-id chain2 \
--keyring-backend test \
--home ../../gm/chain2 \
--node http://localhost:27010

# submit a vote proposal on chain1 to do channel upgrade init
> simd tx gov submit-proposal ./proposal_upgrade_channel.json --from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

> simd tx gov vote 1 yes \
--from validator \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# do channel upgrade try on chain2
> hermes --config config.toml tx chan-upgrade-try \
--dst-chain chain2 \
--src-chain chain1 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

# do channel upgrade ack on chain1 (this aborts upgrade and writes error receipt)
> hermes --config config.toml tx chan-upgrade-ack \
--dst-chain chain1 \
--src-chain chain2 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

# do channel upgrade cancel on chain2 and restore channel
> hermes --config config.toml tx chan-upgrade-cancel \
--dst-chain chain2 \
--src-chain chain1 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

where proposal_update_params.json contains:

{
  "title": "Channel update params",
  "summary": "Update channel params",
  "messages": [
    {
      "@type": "/ibc.core.channel.v1.MsgUpdateParams",
      "params": {
        "upgrade_timeout": {
          "height": {
            "revision_number": "0",
            "revision_height": "0"
          },
          "timestamp": 5000000000
        }
      },
      "authority":"cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn"
    }
  ],
  "metadata": "AQ==",
  "deposit": "100005stake"
}

and proposal_upgrade_channel.json contains:

{
  "title": "Channel upgrade init",
  "summary": "Channel upgrade init",
  "messages": [
    {
      "@type": "/ibc.core.channel.v1.MsgChannelUpgradeInit",
      "signer": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
      "port_id": "transfer",
      "channel_id": "channel-0",
      "fields": {
        "ordering": "ORDER_UNORDERED",
        "connection_hops": ["connection-0"],
        "version": "{\"fee_version\":\"ics29-1\",\"app_version\":\"ics20-1\"}"
      }
    }
  ],
  "metadata": "AQ==",
  "deposit": "100005stake"
}

Unsuccessful test where governance of chain A cancels the upgrade after chain A executes ChanUpgradeAck.

I was able to test this locally and after governance executes the cancellation there is an error receipt and relaying cancel to the counterparty does cancel the upgrade on its side as well. These are the commands I used:

# create channel between chain1 and chain2
> hermes --config config.toml create channel --a-chain chain1 \
--b-chain chain2 \
--a-port transfer \
--b-port transfer \
--new-client-connection 

# submit a vote proposal on chain1 to do channel upgrade init
> simd tx gov submit-proposal ./proposal_upgrade_channel.json --from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

> simd tx gov vote 1 yes \
--from validator \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# send transfer packet from chain1 to chain2
# so that chain1 does not move to FLUSHCOMPLETE on ack
> simd tx ibc-transfer transfer transfer channel-0 cosmos14py05zhnktwjuj4l537va8mre3j7qsx4frahew  100samoleans \
--from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# do channel upgrade try on chain2
> hermes --config config.toml tx chan-upgrade-try \
--dst-chain chain2 \
--src-chain chain1 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

# do channel upgrade ack on chain1
> hermes --config config.toml tx chan-upgrade-ack \
--dst-chain chain1 \
--src-chain chain2 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

# submit a vote proposal on chain1 to do channel upgrade init
> simd tx gov submit-proposal ./proposal_upgrade_cancel.json --from cosmos1vdy5fp0jy2l2ees870a7mls357v7uad6ufzcyz \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

> simd tx gov vote 2 yes \
--from validator \
--chain-id chain1 \
--keyring-backend test \
--home ../../gm/chain1 \
--node http://localhost:27000

# do channel upgrade cancel on chain2 and restore channel
> hermes --config config.toml tx chan-upgrade-cancel \
--dst-chain chain2 \
--src-chain chain1 \
--dst-connection connection-0 \
--dst-port transfer \
--src-port transfer \
--src-channel channel-0 \
--dst-channel channel-0

where proposal_upgrade_channel.json contains:

{
  "title": "Channel upgrade init",
  "summary": "Channel upgrade init",
  "messages": [
    {
      "@type": "/ibc.core.channel.v1.MsgChannelUpgradeInit",
      "signer": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
      "port_id": "transfer",
      "channel_id": "channel-0",
      "fields": {
        "ordering": "ORDER_UNORDERED",
        "connection_hops": ["connection-0"],
        "version": "{\"fee_version\":\"ics29-1\",\"app_version\":\"ics20-1\"}"
      }
    }
  ],
  "metadata": "AQ==",
  "deposit": "100005stake"
}

and proposal_upgrade_cancel.json contains:

{
  "title": "Channel upgrade cancel",
  "summary": "Channel upgrade cancel",
  "messages": [
    {
      "@type": "/ibc.core.channel.v1.MsgChannelUpgradeCancel",
      "signer": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn",
      "port_id": "transfer",
      "channel_id": "channel-0"
    }
  ],
  "metadata": "AQ==",
  "deposit": "100005stake"
}

[crodriguezvega]

Besides the e2e that we have added, there is also a number of test cases covered in hermes using the step functions to set up the right conditions.