`revertedWith` failing when using local Hardhat node

[robercano]

Describe the bug When unit testing in a local hardhat node accessible through localhost endpoint with ethereum-waffle 4.0.7, the to.be.revertedWith matcher fails with the following reason:

TypeError: errorString.startsWith is not a function
      at decodeRevertString (./node_modules/@ethereum-waffle/provider/dist/cjs/revertString.js:41:21)
      at onError (./node_modules/@ethereum-waffle/chai/dist/cjs/matchers/revertedWith.js:12:367)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)

Following the code to revertString.js it seems that getHardhatErrorString is not able to parse the revert message. Instead the getGanacheErrorString is used and an object is returned:

{
  message: "Error: VM Exception while processing transaction: reverted with reason string 'AccessControl: account 0x70997970c51812dc3a010c7d01b50e0d17dc79c8 is missing role 0x0000000000000000000000000000000000000000000000000000000000000000'",
  data: '0x08c379a000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000094416363657373436f6e74726f6c3a206163636f756e7420307837303939373937306335313831326463336130313063376430316235306530643137646337396338206973206d697373696e6720726f6c6520307830303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030000000000000000000000000'
}

Changing the following line in revertString.js:

return (_a = callRevertError === null || callRevertError === void 0 ? void 0 : callRevertError.error) === null || _a === void 0 ? void 0 : _a.data;

to

return (_a = callRevertError === null || callRevertError === void 0 ? void 0 : callRevertError.error) === null || _a === void 0 ? void 0 : _a.data.data;

(notice the double .data.data at the end) seems to do the trick.

My guess is that Hardhat has updated the way they emit the revert message in localhost and ethereum-waffle is not able to parse it anymore. When unit testing using internal Hardhat, the unit tests work correctly, which tells me it is only a problem when running the local instance of Hardhat.

To Reproduce

• Run a local instance of Hardhat 2.12.2
• Use ethereum-waffle 4.0.7
• Use the revertedWith matcher to catch a revert

Software versions

• ethereum-waffle 4.0.7
• @nomiclabs/hardhat-waffle 2.0.3
• @nomiclabs/hardhat-ethers 2.1.1
• hardhat 2.12.2
• Package manager: yarn
• Node version: 16.14.0
• Solidity version: 0.8.14

[rzadp]

Thanks, we will double down on this.

My guess is that Hardhat has updated the way they emit the revert message in localhost and ethereum-waffle is not able to parse it anymore. When unit testing using internal Hardhat, the unit tests work correctly, which tells me it is only a problem when running the local instance of Hardhat.

That sounds like it. We do unit tests against different versions of in-memory Hardhat, but looks like we're gonna have to expand those tests with localhost Hardhat.

@robercano Could you share your exact process of starting the localhost instance of Hardhat? Might come in handy for debugging. (like through npx, or differently?)

[robercano]

Great! Thanks for the prompt reply.

We are currently using nx so the actual command line is: yarn nx run contracts:hardhat-localnode

which in turn executes: hardhat node --hostname 0.0.0.0

Let me know if you need more context.

[jakvbs]

Hi @robercano, can you please send some example test where the problem occurs? Because I've reproduced all your steps and I cannot reproduce the error.

[robercano]

I've tried all morning to prepare a repo but I cannot make it fail. I've used the same package.json and yarn.lock as in the original repo, but it works properly in the reproduction repo, so I'm not sure what to say. I guess it works and we just have a bad package. I've noticed that the ethers package package.json is different in the 2 repos for the same exact version of ethers, so maybe we cached something wrong. I've tried to remove the cache, update the packages and allow to update the checksums, and more things, but cannot reproduce it in a new repo. In our repo it still fails. I guess you can ignore this until we figure out what's going on! Thanks a lot a sorry for the noise.

[jakvbs]

Please let me know how things are going and if there is indeed something wrong we will reopen the issue.