Unrecognized custom error messages while in delegatecall

[RayXpub]

Hi @PaulRBerg!

Loving the PRB proxies so far but I seem to be running into an issue when trying to revert using custom errors while in a delegatecall. Initially I thought this was due to the fact the contract B custom errors could not be visible while executing it within the context of contract A (i.e PRBProxy) so I created an Errors library storing all custom errors which I then imported in both the PRBProxy and contract B but still I get : Error: VM Exception while processing transaction: reverted with an unrecognized custom error.

Here is some pseudocode:

library Errors {
  error TestErrorMsg();
}

PRBProxy {}

Contract B {
    function testError() {
        revert Errors.TestErrorMsg();
    }
}

[PaulRBerg]

Hi @RayXpub! Glad you like PRBProxy.

I created an Errors library storing all custom errors which I then imported in both the PRBProxy

I don't think that this is enough for the custom errors to be included in the ABI of the PRBProxy contract. You'd have to use the library custom errors somehow - otherwise the compiler will simply not include the library in the generated bytecode.

You may have to fork PRBProxy and define your custom errors inside it, not in a third-party library. @cleanunicorn has investigated this use case at length in #38.

[RayXpub]

Very interesting...

I don't think that this is enough for the custom errors to be included in the ABI of the PRBProxy contract.

The odd thing here is I tried the same logic but instead of using a custom error simply use a string constant in the library and then using it as a revert message, and it works...

library Errors {
  string public constant TEST_ERROR_MSG = "1";
}

PRBProxy {}

Contract B {
    function testError() {
        revert(Errors.TEST_ERROR_MSG);
    }
}

So it seems it includes the constant variables but not the custom errors...

You'd have to use the library custom errors somehow - otherwise the compiler will simply not include the library in the generated bytecode.

I also tried that by moving the PRBProxy custom errors to the library but that still did not work (PRBProxy custom errors where recognised but not contract B's).

Thanks for the quick response, not sure if there is way to solve this besides including all target contracts custom errors directly in the PRBProxy which is quite impractical.

[PaulRBerg]

The odd thing here is I tried the same logic but instead of using a custom error simply use a string constant in the library and then using it as a revert message, and it works..

Yep, that's expected. Revert reason strings are stored as is in the revert call, which is why they are so notoriously expensive.

I also tried that by moving the PRBProxy custom errors to the library but that still did not work (PRBProxy custom errors where recognised but not contract B's).

By "use" I meant one of the following:

1. Define them within the scope of PRBProxy.
2. Literally use them in a function in PRBProxy, as in function foo() { revert Errors.TestErrorMsg(); } even if you never need foo.

Thanks for the quick response, not sure if there is way to solve this besides including all target contracts custom errors directly in the PRBProxy which is quite impractical.

Happy to help, but I'm sorry that I couldn't do more.

Though I must say that this isn't a limitation of PRBProxy per se, but rather of custom errors themselves and the testing framework that you are using. Related thread in the Hardhat repository:

NomicFoundation/hardhat#1618

With time, I'm confident that more and more testing frameworks will provide more suggestive logs when testing custom errors that are not part of the underlying contracts ABIs.

Relevant links:

• sig.eth.samczsun.com/
• 4byte.directory

[RayXpub]

By "use" I meant one of the following:
Define them within the scope of PRBProxy.
Literally use them in a function in PRBProxy, as in function foo() { revert Errors.TestErrorMsg(); } even if you never need foo.

Got it, but yes that is quite impractical.

Thanks again for your responses 🙏, I will closely follow the open issues.

[PaulRBerg]

It is impractical! I'm sorry.

Out of curiosity - what framework are you using for testing? Asking because if you were to use Foundry/ Forge, you could test the custom errors like this:

vm.expectRevert(
    abi.encodeWithSelector(MyContract.CustomError.selector, ARG_1, ARG_2)
);

Reference.

[RayXpub]

I am using hardhat. Interesting to know that this is possible with foundry which I am not familiar with yet.

[PaulRBerg]

I highly highly recommend you take a look at Foundry. Many things which are problems in Hardhat are non-problems in Foundry.

You can start with the Foundry Book.

[RayXpub]

Duly noted, will start looking at it asap. Thanks 🙏