Same tx might be sent multiple times in azero.handle_event by the same relayer, which comsumes

[hats-bug-reporter]

Github username: --
Twitter username: --
Submission hash (on-chain): 0x8202337a6121a0bbb9e6f6f0a2d2f93569de22615ada1c3434bf6511bd999fee
Severity: low

Description:
Description
Same tx might be sent multiple times in azero.handle_event by the same relayer, which consumes unnecessary gas

In azero.handle_event, while receiving CrosschainTransferRequest event from Aleph-Zero, the function will first check if the event has been processed in azero.rs#L110-L117, and here BlockNumber::Finalized is used to query from the finalized blocks on Ethereum

If the tx is newly created, and this is the first time to process the event, the function will go into the while loop, because this even is new, the code will skip the if condition, and executes the rest of the code.
In azero.rs#L155-L162, a receiveRequest tx will be sent to Ethereum.

Because a tx can be pending in mempool for a long time and can be executed in a long time after the user submit the transaction

So if the tx is pending in mempool, the function will contine the while loop, because BlockNumber::Finalized is used.
And at the same time, the if condition will be skipped because BlockNumber::Latest is used, and Latest means:

‍The latest block is the most recent block to be built and validated by Ethereum validators. The latest block should be used with caution because there are no guarantees that the Beacon Chain will not get reorganized, and this block becomes an Uncle Block, or a block that was not added to the canonical chain.

In such case, the Most.receiveRequest will be called again, and in Most.receiveRequest the fuction will not retert if the same committee member calls the function twice

[fbielejec]

There is no one good fix for this. Some steps we are taking:

• longer confirmation times
• longer poll interval
• defensive handling