-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check if message already delivered #23
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good to me. I left a question about error handling for the receive message check.
return messageDestinationID == allowedDestinationID | ||
} | ||
|
||
func isAllowedRelayer(allowedRelayers []common.Address, eoa common.Address) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should relayers be destination specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the code level, this particular check is ensuring that the relayer EOA that will send the tx to the destination is included in the Teleporter message's list of allowed relayers. The function above checks that the EVM client that will send the tx is sending to the destination chain ID included in the Teleporter message.
At the architectural level, DestinationClient
is the entity responsible for sending the tx to the correct destination chain. MessageRelayer
s should be composed of exactly one DestinationClient
, so in that sense, relayers are destination specific.
zap.String("destinationChainID", destinationChainID.String()), | ||
zap.String("teleporterMessageID", teleporterMessage.MessageID.String()), | ||
) | ||
return false, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the caller should look at the err to distinguished between the message has been received and error conditions. Do the callers do that currently? How should the caller handle errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The call to ShouldSendMessage
is valid regardless of the value of the boolean, as long as the error is nil. We perform that check here: https://github.com/ava-labs/awm-relayer/blob/2060ab680cbd1a2501a87ac3ec01d6cd9da79f37/relayer/message_relayer.go#L80-L95
I added a comment to the MessageManager
interface noting that the boolean should be ignored if a error is returned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me at a high level. I like the ShouldSendMessage
interface a lot. I left a few minor suggestions.
m.logger.Info("Relayer EOA not allowed to deliver this message.") | ||
return false, nil | ||
} | ||
if !isDestination(destinationChainID, destinationClient.DestinationChainID()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check seems redundant given that we look up the destination client by the chain ID already. If we choose to keep it, could we move this to right after the destinationClient
is looked up from the destinationClients
map?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I've removed it altogether, but left the corresponding method in DestinationClient
, as it makes sense as a getter for that interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just nits for changing comment and removing isDestination
since not used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left one small comment on something mostly unrelated. The PR looks good to me 👍
…/awm-relayer into check-message-already-delivered
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To small nits, but otherwise LGTM
0a1a368
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Why this should be merged
MessageManager
andDestinationClient
interfaces more clearly defined roles.How this works
TeleporterMessenger
contract methodmessageReceived
(https://github.com/ava-labs/teleporter/blob/main/contracts/src/Teleporter/TeleporterMessenger.sol#L492) inMessageManager:ShouldSendMessage
. If the message has already been received, return earlyDestinationClient
and intoMessageManager
.DestinationClient
now only manages interaction with the destination chain via the relayer EOA, whileMessageManager
manages protocol unpacking and delivery decision logic.How this was tested
CI, Teleporter integration tests, & manual testing.