Hermes ft-transfer returns unhelpful error when using non-Open channel

[adizere]

Crate

ibc-relayer-cli

Summary of Bug

If we invoke Hermes ft-transfer with a ChannelEnd in state Init (as opposed to Open), then the error returned is not very helpful:

hermes --json tx raw ft-transfer ibc-1 ibc-0 transfer channel-2 10000 -o 1000 -n

{"result":"tx error: failed with underlying cause: deliver_tx reports error: log=Log("failed to execute message; message index: 0: packet failed basic validation: invalid destination channel ID: identifier cannot be blank: invalid identifier")","status":"error"}

Version

b1c4bb8

Steps to Reproduce

• start two chains ibc-0 and ibc-1
• create a connection between them
  • hermes create connection ibc-0 ibc-1
  • suppose that the newly created connection on chain ibc-0 (side a) has connection id connection-2
• start the channel open handshake on side ibc-0 on top of connection connection-2
  • hermes tx raw chan-open-init ibc-0 ibc-1 connection-2 transfer transfer
  • suppose that the newly created channel has id channel-3, note that this channel has state Init
• now try to submit a ft-transfer to destination ibc-1 and source ibc-0 / channel-3
  • hermes --json tx raw ft-transfer ibc-1 ibc-0 transfer channel-3 10000 -o 1000 -n 2

The returner error will be:

{"result":"tx error: failed with underlying cause: deliver_tx reports error: log=Log("failed to execute message; message index: 0: packet failed basic validation: invalid destination channel ID: identifier cannot be blank: invalid identifier")","status":"error"}

Acceptance Criteria

• Hermes will not try to send a MsgTransfer on a non-open channel
• Hermes will return a more helpful message when ft-transfer is invoked for a non-open channel

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned