Transfers to `znam` addresses via ibc drain the balance of the relayer.

[hkey0]

Hello, I apologize for going out of template.

bug

If I do an ibc transfer to znam addresses with XCS contracts deployed on Osmosis, hermes gets stuck, constantly trying to send tx to namada and draining the balance of the relayer address.

my question

Is there a command like drop-packets to fix this temporarily? Otherwise I will have to redeploy all contracts and set up a relayer to prepare a new testbed.

[yito88]

Thank you for reporting. Could you share the operations? Did you generate a MASP shielded transaction with ibc-gen-shielded on the destination Namada? There is no command to drop a packet, I think.

[hkey0]

Thank you for reporting. Could you share the operations? Did you generate a MASP shielded transaction with ibc-gen-shielded on the destination Namada? There is no command to drop a packet, I think.

I am making a transaction through the XCS contract to transfer the output funds to a znam adress. This is the full explanation of what I do

I don't know how to explain it in more detail

[yito88]

Did you try IBC shielding transfer as per the following guide? IBC shielding transfer to Namada znam address requires MASP shielded transaction generation in advance and setting it to ICS-20 packet's memo field. https://docs.namada.net/users/ibc#shielding-transfer

[hkey0]

Did you try IBC shielding transfer as per the following guide? IBC shielding transfer to Namada znam address requires MASP shielded transaction generation in advance and setting it to ICS-20 packet's memo field. https://docs.namada.net/users/ibc#shielding-transfer

Its okey. What about the bug?

[yito88]

I need more details. Could you get the MASP transaction successfully? The MASP transaction (it's not a Namada transaction, it's set into the ICS-20 memo field) should correspond to the following IBC transfer. Did you check it? Also, can you share the failure info of the corresponding transaction (for MsgRecvPacket?) in Hermes logs?

[hkey0]

I need more details. Could you get the MASP transaction successfully? The MASP transaction (it's not a Namada transaction, it's set into the ICS-20 memo field) should correspond to the following IBC transfer. Did you check it? Also, can you share the failure info of the corresponding transaction (for MsgRecvPacket?) in Hermes logs?

I know this may not be in line with open-source ethics, but there will be a lot of one-on-one conversations. Can we chat with you on discord at least until we clarify the problem and come to a conclusion?

[yito88]

Sorry for the late response. I found that Hermes checked a transaction commit and retried to submit another transaction with the same IBC message because the failed transaction didn't emit any event. The checking process was changed in the cosmos handler, but the Namada one is based on the old code of the upstream. I'll fix it as the cosmos handler does.

[yito88]

Ah, sorry, I misunderstood. The failed transaction result is handled as expected. So, the retries are expected. The packet relay should be retried by the timeout because Hermes doesn't know whether the transaction failure is temporary or not.