Skip to content

Support custom error selectors in revertedWithCustomError Chai matcher #6484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ItsNickBarry opened this issue Mar 18, 2025 · 2 comments · May be fixed by #6511
Open

Support custom error selectors in revertedWithCustomError Chai matcher #6484

ItsNickBarry opened this issue Mar 18, 2025 · 2 comments · May be fixed by #6511
Assignees
@ChristopherDedominici
Labels
status:ready This issue is ready to be worked on

Comments

@ItsNickBarry
Copy link
Contributor

ItsNickBarry commented Mar 18, 2025 •
edited
Loading

Describe the feature

What is the reasoning behind requiring an interface to be passed to revertedWithCustomError? The error name string itself should be enough to run the assertion.

In my case, the contract I'm testing takes a custom error selector as a parameter and reverts with that error using assembly. The errors do not exist in the contract ABI, so I have to pass in a fake interface to the matcher.

const customError = 'TestError';

const placeholder = {
  interface: new ethers.Interface([`error ${ customError }()`]),
};

const selector = placeholder.interface.getError(customError)?.selector!;

await expect(
  contract.revertWithCustomErrorSelector(selector),
).to.be.revertedWithCustomError(placeholder, customError);

If this process could be encapsulated within the matcher code, the matcher could be used like this:

await expect(...).to.be.revertedWithCustomError(customError);
// or
await expect(...).to.be.revertedWithCustomError(selector);

Maybe the withArgs extension needs the full interface to process its arguments. In that case, maybe require the full error signature?

await expect(...).to.be.revertedWithCustomError('TestError(uint256)`);

Search terms

revertedWithCustomError

Similar to #5818, but more specifically related to errors that do not exist on the contract being tested.
@github-project-automation github-project-automation bot moved this to Backlog in Hardhat Mar 18, 2025
@ChristopherDedominici
Copy link
Contributor

Hi @ItsNickBarry, the reason revertedWithCustomError requires an interface is to resolve the full error signature, especially when the custom error includes parameters (e.g.: ErrorName(uint256), ErrorName(bool, bool), etc.).
Just passing the error name ErrorName is ambiguous, and without more context, the matcher can't determine the correct selector.

So, not requiring the full error signature and instead relying on an interface was a deliberate design choice to balance usability and clarity.

@ItsNickBarry ItsNickBarry linked a pull request Mar 27, 2025 that will close this issue
Draft
@ChristopherDedominici
Copy link
Contributor

Hi @ItsNickBarry, thanks for opening the PR! I took a quick look and noticed that tests are currently missing. At the moment, we're quite focused on Hardhat 3 and not planning to add new functionalities to hardhat-chai-matchers. That said, we’d be happy to merge the PR if it includes both manual testing and automated tests.

I also saw that you were having trouble using the plugin locally, perhaps you could try using verdaccio? I gave it a shot on my end and was able to get the plugin working.

What to do:

  • install Verdaccio
  • build the hardhat-chai-matchers package via pnpm build
  • bump the package version to 2.0.9, otherwise verdaccio will (rightfully) complain that the package already exists
  • publish the package in verdaccio: pnpm publish --registry http://localhost:4873 --no-git-checks
  • install the package in an example project using: pnpm add @nomicfoundation/hardhat-chai-matchers --registry http://localhost:4873/

@ChristopherDedominici ChristopherDedominici added status:ready This issue is ready to be worked on and removed status:triaging labels Apr 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ChristopherDedominici ChristopherDedominici

Labels
status:ready This issue is ready to be worked on
Projects
Hardhat
Status: Backlog
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Custom error without Interface parameter ItsNickBarry/hardhat
2 participants
@ItsNickBarry @ChristopherDedominici