-
Notifications
You must be signed in to change notification settings - Fork 9
Validate client's Ethereum address options #223
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.
Made a recommendation to use lodash/*
instead of lodash.*
here: #225,
and added a few comments, but otherwise lgtm 👍 great.
if (await mainnetProvider.getCode(this.factoryMainnetAddress) === '0x') { | ||
throw new Error( | ||
`Data union factory contract not found at ${this.factoryMainnetAddress}, check StreamrClient.options.dataUnion.factoryMainnetAddress!` | ||
) | ||
} | ||
|
||
const factoryMainnet = new Contract(this.factoryMainnetAddress!, factoryMainnetABI, mainnetWallet) | ||
const factoryMainnet = new Contract(this.factoryMainnetAddress, factoryMainnetABI, mainnetWallet) |
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.
👍
'dataUnion.factoryMainnetAddress', | ||
'dataUnion.factorySidechainAddress', | ||
'dataUnion.templateMainnetAddress', | ||
'dataUnion.templateSidechainAddress' |
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.
Neat, as-is this is an improvement, but note this will silently stop working if a config is renamed or if new EthereumAddress config items are added. Developer always needs to remember to update this list of paths. A shame since we do already have the type information.
I wonder if we should do something like I described in slack, where we have an unsafe type at API boundaries, then a safe type internally and the only way to get from unsafe to safe type is to pass through the isAddress
validator.
If user overrides some option in
StreamrClientOptions
, we validate that value already in the constructor. Using the option is therefore easier in the code, as we know that the value is always valid.In this PR we validate all overriden Ethereum addresses. Open question: Should we validate also other overriden fields this way? E.g.
restUrl
,maxPublishQueueSize
...