wrong block number in xcm transfer on kusama in case of 2 transfers at same block

[dzmitry-lahoda]

PD.js and Subscan show ..51 block on Kusama, while PH shows ..51 and ..55

https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama.api.onfinality.io%2Fpublic-ws#/explorer/query/0xfe727b96fc3c33255745e181bc213ce39845b739a3e89bbbc8ded15e5319c4a6

https://kusama.subscan.io/xcm_transfer?address=&fromChain=all&toChain=all&startDate=&endDate=&startBlock=18225351&endBlock=18225351&timeType=block&result=all&protocol=all&filterParaId=

[sourabhniyogi]

Thank you for your report, we rematched this one but the source is we do real-time matching in the indexers that match heuristic constraints (messagehash match? receiver match? transaction fee + amount received = amount received ... or close, to support multihop) and it tends to break (at least, from your point of view) when there are identical message hashes, low amount sent and/or repeated transactions from the same sender/receiver.

We aim to solve this with the "Topic" mechanism:
paritytech/polkadot#7234
which I believe is partially covered in IBC -- no heuristic matching is required. However, for your XCM plans, you should use the "SetTopic" instruction and make our life easier.