search

icon-project / xcall-multi

Apache License 2.0
10 stars 8 forks source link

No way to receive reqId and data to make the final executeCall #321

Open sharma66mahesh opened 1 month ago

sharma66mahesh commented 1 month ago

Describe the bug A lot of my Balanced swap transactions from ICON to Avalanche have been stuck for almost a day. And it seems the final executeCall is not being called on the destination chain. I don't seem to find the events on the recvmessage() call on the destination chain that I'd expect to give out reqId and data so that I can make the final executeCall myself.

To Reproduce Let's take a look at this transaciton: 0x8c4956C53408c8B0E5D6B1403c57d85D8576B533 that is swapping bnUSD(on ICON) for AVAX(on Avax).

For this, I assume the corresponding recvMessage() transaction on AVAX is 0x1ee789806e11bb3afaef1380d55cc42f24ec9fbf9b8e32273a6a99ff7a39912f.

But the transaction generates no info whatsover on what the reqId or data was; something that would be needed to make the executeCall and complete the swaps.

Further, I checked the xcallscan.xyz/api. But that doesn't provide any info on that either.

Expected behavior Need the following info:

  1. The id that can be used to track the xcall transactions across chains?
  2. The reqId and data should be available so that the user can make the final executeCall themselves, and not have to wait for days to just get a token swap done.

Additional context (For the above discussed example) Additionally, I can only guess the corresponding recvMessage() transaction on AVAX (Destination chain), based on the timestamp, since the sn on the source ICON transaction and the _connSn on the destination AVAX chain are different. What would be the way to track them across the source and destination chains? image

image

izyak commented 1 month ago

In this transaction, if you see the logs, there are 2 Message events, meaning 2 separate connections are being used. image

This means, there should be 2 transactions on the avax side to receive the message. If there are not 2 recvMessage transactions on the BSC, then I think we can assume one of the relay is down. The reqId and data is generated on the 2nd recvMessage call, when message from all the connection comes in.