batchTransferdue to high slippage, not enough liquidity, etc. In These cases, executor automatically prepares a refund and executes it on the source chain. In order for this to work, the BatchTransfer contract on the source chain needs to implement
executeMessageWithTransferRefund, so let's add it:
executeMessageWithTransfer. If the execution of this function also fails, the message execution then enters a "failed" status, and the funds will be locked in the BatchTransfer contract.
executeMessageWithTransferon the destination chain. Since the
executeMessageWithTransferinterface is payable, this usage is supported.
executeMessageWithTransferto cover the fee introduced by chaining the additional message.
sendMessage()call is incurring. Let's take a look at how the message fee is calculated in the MessageBus contract:
abi.encodeto encode your message, the message length is likely fixed. If you happen to have variable length fields in your message, you should add a safe margin to the
add_payable_value_for_executionto reduce the chance of having message execution reverted.