Function: send(uint32 _dstEid, string calldata _message, bytes calldata _options)
This function allows any user to send any message to the application in the _dstEid chain.
Inputs
_dstEidControl: Full control.
Constraints:
peersshould contains the_dstEid. Only owner can set up.Impact: The ID of the destination chain where the message will be sent.
_messageControl: Full control.
Constraints: N/A.
Impact: The message to be sent.
_optionsControl: Full control.
Constraints: Should be
OPTION_TYPE_3.Impact: Determines the gas limit and amount of
msg.valueto include.
Branches and code coverage
Intended branches
_messageis sent successfully.The caller pays more fees than necessary and receives the excess back.
Negative behavior
The provided fee is not enough.
The message is empty.
There is an invalid type of additional
_options._dstEidis not supported.
Function call analysis
_lzSend(_dstEid, _payload, options, MessagingFee(msg.value, 0), payable(msg.sender)) -> endpoint.send{ value: messageValue }(MessagingParams(_dstEid, _getPeerOrRevert(_dstEid), _message, _options, _fee.lzTokenFee > 0),_refundAddress);What is controllable?
_dstEid.If the return value is controllable, how is it used and how can it go wrong?
receiptis just used to be returned from this function. Contains GUID, nonce, and fee.What happens if it reverts, reenters or does other unusual control flow? If the provided fee is greater than necessary, the caller will receive excess back.
_lzSend(_dstEid, _payload, options, MessagingFee(msg.value, 0), payable(msg.sender)) -> _getPeerOrRevert(_dstEid)What is controllable?
_dstEid.If the return value is controllable, how is it used and how can it go wrong? Returns the peer address where the message will be delivered.
What happens if it reverts, reenters or does other unusual control flow? Reverts if
_dstEidis not supported.