IBC Transfer was constructed with bad Timeout Height and has not been received in destination chain

[ArielLeza]

An IBC transfer transaction from Archway to Andromeda failed, and attempts to resend the transaction or cancel it have encountered issues with packet commitments and acknowledgment.

via archway UI (worked) - https://www.mintscan.io/archway/tx/32262AA63A3A89BC6FCF47086D682FDC94458DC78F454DE1F23307C4099600EC
via keplr IBC transfer (lost) - https://www.mintscan.io/archway/tx/8B7DA3BC0859436C1D6C3C64AEC109CEF57EC46B228FE744B21ED66A45F6F61F?height=5806457&sector=message

detailed JSON for the TX: https://explorer.nodestake.org/archway/tx/8B7DA3BC0859436C1D6C3C64AEC109CEF57EC46B228FE744B21ED66A45F6F61F (lost)

https://explorer.nodestake.org/archway/tx/32262AA63A3A89BC6FCF47086D682FDC94458DC78F454DE1F23307C4099600EC (worked)

sender wallet on archway: https://www.mintscan.io/archway/address/archway1c5ph8wdcedwx2k6f5q6le0dwju9juuje7kzv76

both are successful and look similar, however the one i conducted from keplr UI I DONT SEE the tokens in the destination ANDR address for some reason

i see 1 pending tx on mapofzones, i wonder if it's mine

i tried to debug via CLI/IBC commands and also reading the raw hson files - and what i've come so far is that on the failed tx, revision_number being 1 and revision_height being lower than the block (i believe this is the issue, but i am unable to run hermes commands or manually generate the tx because the wallet i used is on ledger, and i could not build a custom tx via any UI)

Commands and Outputs
Initial Query of Packet Acknowledgement:

archwayd query ibc channel packet-ack transfer channel-97 7150 --node https://rpc.mainnet.archway.io:443 --chain-id archway-1


Error:

portID (transfer), channelID (channel-97), sequence (7150): invalid acknowledgement

Query of Packet Commitment:

archwayd query ibc channel packet-commitment transfer channel-97 7150 --node https://rpc.mainnet.archway.io:443 --chain-id archway-1


Error:

portID (transfer), channelID (channel-97), sequence (7150): packet commitment not found

Attempt to Query Unreceived Packets:

andromedad query ibc channel unreceived-packets transfer channel-11 --sequences=7150,7151 --node tcp://127.0.0.1:26657 --chain-id andromeda-1


Output:

height:
  revision_height: "3725547"
  revision_number: "1"
sequences: []

Packet Receipt Query:

andromedad query ibc channel packet-receipt transfer channel-11 7150 --node tcp://127.0.0.1:26657 --chain-id andromeda-1


Output:

proof: <proof data>
proof_height:
  revision_height: "3725553"
  revision_number: "1"
received: true

Transaction Query:

archwayd query tx 8B7DA3BC0859436C1D6C3C64AEC109CEF57EC46B228FE744B21ED66A45F6F61F --node https://rpc.mainnet.archway.io:443 --chain-id archway-1


Output:

{
  "height": "5806457",
  "txhash": "8B7DA3BC0859436C1D6C3C64AEC109CEF57EC46B228FE744B21ED66A45F6F61F",
  "code": 0,
  "data": "12380A312F6962632E6170706C69636174696F6E732E7472616E736665722E76312E4D73675472616E73666572526573706F6E7365120308EE37",
  "logs": [ ... ]
}

Observations and Conclusions
Packet Commitment Not Found: The packet commitment for the sequence 7150 on channel 97 was not found. (however even for 7151 which did work i did not see a commitment)
Packet Receipt on Andromeda: The packet was received on Andromeda, but no further acknowledgment or packet commitment could be confirmed on Archway.
Revision Numbers and Heights: The revision number being 1 and the revision height being lower than the block itself might be indicative of an issue but needs further validation.

response from the chain's teams:
"Hi I shared with the relayers for the Andromeda path and they did the necessary tests even via Keplr and everything seems to be fully functional. They also shared that you should have received the transfer here https://ping.pub/andromeda/tx/33DD546F90E34DE59AFEF9AB13B33B41B259EC35DECFF7D648E5A6014153394E"

however you can see it was never received:

https://andromeda.explorers.guru/account/andr1c5ph8wdcedwx2k6f5q6le0dwju9juujenkk2gq

you can see it was never received

you can see a test transaction i did right away: https://www.mintscan.io/archway/tx/C68CC20C8DBAE90B44B4C6AD37533023A5915A5E1C289A28C1D043F363178DED?sector=logs check the ibc ack

"Packet Timeout Height 5806808-5806808" while tx height is 5,806,714

in the one that is stale: https://www.mintscan.io/archway/tx/32B8370C39DF0EADFA7D97071DA9C6D06B0164DCFCA8DA99CAE2CE4B53339E6C?sector=logs Packet Timeout Height 1-3723625 while tx height is 5,806,462

it seems that ack was registered sucsesfuly

i've seen some answers that state that "one would need to run a relayer such as the golang or hermes relayer. You'd need to send a timeout message for the packets you wish to timeout. You could also try to reach out to relayers and ask them to timeout the packets for you. You'd need to know which channel/port and sequences are in question"

can this be done without signing with the wallet that generated the IBC tx?

[crodriguezvega]

Hi @ArielLeza. I am sorry to hear that you have experienced some issues. I took a look at it and these are my findings:

I see on Mintscan that the IBC transfer was acknowledged on Archway, so I looked on Andromeda for receive transaction by searching for the receive event and it looks like the transaction succeeded, which would indicate that the tokens were successfully received. I also see on the explorer that the receive transaction is flagged as successful.

So the packet seems to have been received and acknowledged, which would make it impossible to time out.

Do you have a way to contact Andromeda to investigate in more detail what happened with tx 33DD546F90E34DE59AFEF9AB13B33B41B259EC35DECFF7D648E5A6014153394E?