ethers.js: Invalid ENS name error when a signer is used instead of an address
Hey @ricmoo
I’m creating this issue cause I’ve seen lots of people confused about an ENS related error being thrown when a signer is used instead of an address. To make things worse, the signer gets JSON.stringify
d so the error is HUGE sometimes.
Have you consider treating this as a special case and throwing something like “hey, you should use an address instead of a signer”? Or maybe add a toJSON
to the abstract signer to at least avoid those huge errors?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 11
- Comments: 26 (5 by maintainers)
Commits related to this issue
- Better errors when non-string address or ENS name is passed into Contracts or provider methods (#1051). — committed to ethers-io/ethers.js by ricmoo 3 years ago
Example problematic code:
Yields confusing error:
Fix:
I guess extra confusing for typescript users, as the types are happy with it, only breaks at runtime.
This has already been added to my local v6. You should actually generally call
.getAddress()
instead of.address
, since.address
is not part of the Signer API (most signers do not have synchronous access to their address).For v5, I can add a condition like that to the JavaScript side, but cannot change the signature to allow Signer and Contract since that would break any existing sub-classes.
One of my deepest regrets 🥲 We need to come up with a better way of doing this. Originally that
ethers
object just contained some helpers, and some users asked for it to re-export the actualethers
because the name clash made importing it annoying.This problem mostly happens when users pass a Signer or Contract instead of an address. I think something that would improve it is checking if the value is a string, and only throw ENS-related errors in that case.
This should be better in 5.5.0. The error thrown is more meaningful and does not mention ENS.
In v6,
Signers
andContracts
inheritAddressable
, so they are valid to passed in for addresses, but in v5 this change seems riskier than I’d prefer, so the current behaviour is preserved, but with better errors. 😃Thanks! 😃
Hey thanks for the quick reply ! That’s totaly on me. I found out the problem 5 mins after posting (stupid bad venv ariable names hidden deep in my code…). Sorry for the inconvenience !
There is also no
getSigners
, maybe something else Hardhat added?My guess is you want to call
deploy(owner.getAddress())
instead?I’m still getting an error when I try to run this code. I’m new to frontend smart contract work, so this may be an obvious error, but I can’t figure out what I’m doing wrong here:
I get the owner.toString() to come back as expected, but afterwards I get the ‘invalid ENS name’ error
Hey there, same problem as @slhodak if anyone found a solution please let me know
I haven’t looked much into this, but there is no
getContractFactory
on ethers. I think that is something Hardhat adds? Are you using Hardhat? Could there be a problem there?