Ethers v5 doesn't return data field in error for zksync network

[novaknole]

Hey Richard. @ricmoo

So I am at the point of hitting my brain on the wall and hoping you could give me some hints about this.

I am using zksync network and have the following in my tests.

const artifact = await deployer.loadArtifact("Test");
const contract = await deployer.deploy(artifact)
await expect(contract.failsHere()).to.be.revertedWith("failMessage")

Note that I am as well using `"@nomicfoundation/hardhat-chai-matchers": "1.0.6``` which uses ethers v5 and also, in my own code, I am using ethers v5. All the zksync package that I am using also uses ethers v5.

Note that the revertedWith function from chai has the following line in the code:

// error is what ethers returns.
if(!error.data) {throw ...}

So you might think that everything is fine, but the following line doesn't work and to explain this, I will list down scenearios.

await expect(contract.failsHere()).to.be.revertedWith("failMessage")

When the network is zksync

SCENARIO 1: Using zksync packages such that they use v6.

The transaction is made and the returned result(which is an error) contains data field which is an abi encoded error message. Since it contains data, all is good and chai matcher doesn't throw an error(see the above)

SCENARIO 2: Using zksync packages such that they use v5.

Well, in such case, the returned thing from ethers doesn't contain data, but only reason: execution reverted: failMessage and some other things, but not data field. Hence, chai matcher fails and can't do its job.

When the network is hardhat or normal EVM

Well, here it doesn't matter which version of ethers is used. It just works for both as data is returned. I wonder why data field is not returned for zksync network by ethers v5.

---

I wonder if you are aware of this and how can I fix this problem ? Note that I can't use ethers v6 because my project is big and can't really upgrade. If I use zksync packages such that they use ethers v6, then i got dependency problems. So the only way I can do is to use ethers v5 in my project and also use zksync packages such that they use ethers v5.

In such circumstance, I end up in Scenario 2 above. at one point, I thought what if I write my custom revertedWith, but since ether's error returned won't contain data field, I am not sure how to extract the error. getting it from reason doesn't sound right in my opinion.

What would you advise ? :(

[ricmoo]

Can you console.log the data? Keep in mind that an empty data is "0x" which is truthy-true in JavaScript.

[novaknole]

The chai matcher has the following exact code:

const errorData = error.data ?? error.error?.data;

if (errorData === undefined) {
  throw error;
}

When using ethers v6 and latest zsync packages such as they also use ethers v6:

• if I log the error.error.data, it's undefined.
• If I log the error.data, this logs: 0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000b6661696c4d657373616765000000000000000000000000000000000000000000

As we can see, chai matcher check doesn't throw because errorData is defined.

When using ethers v5 and latest zsync packages such as they also use ethers v5, then both logging error.data and error.error.data show undefined in console and since errorData is undefined, it produces the throw. @ricmoo

It's strange that ethers v5 only has this problem for zksync network, but ethers v6 doesn't have this problem at all even for zksync.

[novaknole]

Note that you can exclude chai matchers in the debugging.

Assume the following code:

 const t = await deployer.loadArtifact("Test");
 k = await deployer.deploy(t)

try {
  await k.failsHere()
} catch(err:any){
  console.log(err?.data);
}

For ethers v6 and zksync-deploy package that uses ethers v6 as well, the above code logs the 0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000b6661696c4d657373616765000000000000000000000000000000000000000000

For ethers v5 and zksync-deploy package that uses ethers v5 as well, the above code logs the undefined.

Hence the culprit.

[novaknole]

@ricmoo I think I figured it out.

in ethers v6, data is either in error or in error.error whereas in ethers v5, data field ends up in error.error.error. The chai matcher only checks error.data or error.error.data and not error.error.error.data.

What would you advise ? It seems like zksync-ethers v5 adds one layer of error inside error object or it could be ethers v5

[ricmoo]

It could be ethers or zkSync. I’m not certain.

The way errors are handled was one of the big simplifications (for end developers; more complex for me ;)) v6 introduced. For call exceptions, if there is data, it will be on the error. You shouldn’t ever need to do error.error in v6.

Would it work if you made a custom matcher?

[novaknole]

I guess, I don't have any choice, but to override revertedWith matcher and add error.error.error.data check in there as well. :D

v6 is pretty amazing @ricmoo . I wish I could upgrade to it now.