node: Integrate Transfer Verifier into the Ethereum watcher #4233
Conversation
node/pkg/watchers/evm/watcher.go
Outdated
| @@ -88,7 +94,7 @@ type ( | |||
| // VAA ChainID of the network we're connecting to. | |||
| chainID vaa.ChainID | |||
|
|
|||
| // Channel to send new messages to. | |||
| // Channel to send new messages to. Should be wrapped be a call to `publishIfSafe()` | |||
There was a problem hiding this comment.
| // Channel to send new messages to. Should be wrapped be a call to `publishIfSafe()` | |
| // Channel to send new messages to. Each message should be wrapped by a call to `publishIfSafe()` |
| pubErr := w.publishIfSafe(msg, ctx, tx, receipt) | ||
| if pubErr != nil { | ||
| logger.Error("could not publish message: transfer verification failed", | ||
| zap.String("msgId", msg.MessageIDString()), | ||
| zap.String("txHash", msg.TxIDString()), | ||
| zap.Error(pubErr), | ||
| ) | ||
| } |
There was a problem hiding this comment.
This chunk of code is used 4 more times below. Should we put it inside publishIfSafe and then have that function not return anything?
There was a problem hiding this comment.
My preference is to maintain the return value so that the calling code has an idea of whether or not an error occurred. We could think about reducing code duplication by passing a *logger as an argument to that function and allowing it to print the error message, but then the calling code would need another log call if someone wants to log data that isn't visible to publishIfSafe, e.g. the blockNumber which exists for some instances in this file but not others.
| input string, | ||
| ) ([]vaa.ChainID, error) { | ||
| if len(input) == 0 { | ||
| return nil, errors.New("could not parse input to parseTxVerifierChains: input empty") |
There was a problem hiding this comment.
If we wanted to disable transfer verification on all chains, wouldn't the empty input be a valid case?
There was a problem hiding this comment.
In that case we would just not pass in the flag at all, similar to how someone might omit the flag that enables the governor or sets a coingecko key. I think having a CLI interface where --txVerifierChains='' is a valid input is a bit messy.
There was a problem hiding this comment.
I'm probably misunderstanding how these Go command line flags work, but if you don't provide the flag what does the value default to? My current understanding is it would default to the value you specify in the declaration, which is an empty string; am I greping that wrong?
There was a problem hiding this comment.
Haven't gone deeply into it but basically the flags are parsed into specific variables that you define. In this case the type I used is *string (pointer to a string) so the default value when it's not provided would be nil, (I think) rather than a non-nil string of length 0.
There was a problem hiding this comment.
I did some more testing and patched the code. The latest commit does the following:
- if the CLI flag is an empty string, panic (via logger.Fatal)
- if it's absent, txVerifier is disabled
- if it contains a list of chain IDs, enable Tx Verifier for those chains
publishIfSafe