Open mshakeg opened 11 months ago
My issue is potentially caused by having an importer file that specifically imports a contract from an installed dependency which I'm doing to avoid the issue described in #86
Can you share what is your use case for using a ContractFactory with ABI+bytecode?
The plugin normally expects getContractFactory("ContractName"...)
because that provides access to the source code of the implementation contract, which we use for extracting storage layout information for comparison as part of the upgrade safety checks.
@ericglau in a hardhat project I'm installing a package that has upgradeable contracts, those packages are private but for the purposes of this discussion let's say this package is an openzeppelin upgradeable version of Uniswap/v3-core. Now in my hardhat project that installs this upgradeable @uniswap/v3-core-upgradeable
package I would like to import the upgradeable UniswapV3Factory
abi
and bytecode
from the relevant @uniswap/v3-core
json artifact as shown here. However, as explained in the issue description attempting this fails:
const UniswapV3FactoryContractFactory = new ethers.ContractFactory(UPGRADEABLE_FACTORY_ABI, UPGRADEABLE_FACTORY_BYTECODE, deployerSigner);
const upgradeableUniswapV3Factory = await upgrades.deployProxy(UniswapV3FactoryContractFactory, [], {
initializer: "initialize",
});
With the error:
Error: factory runner does not support sending transactions (operation="sendTransaction", code=UNSUPPORTED_OPERATION, version=6.4.0)
@ericglau it would be great to at least have the option(say called forceDeploy
) to disable/ignore those safety checks.
it would be great to at least have the option(say called forceDeploy) to disable/ignore those safety checks.
We can consider adding an option similar to this.
However, I think your scenario is failing at an earlier step because the deployer
that you are passing in does not seem to be a signer. I notice the same error if I use ABI+bytecode according to your steps but do not pass in a signer when instantiating the contract factory.
If I pass in an actual signer (for example in tests, (await ethers.getSigners())[0]
), I get a different error (which is the one I expect because source code is not found): The requested contract was not found. Make sure the source code is available for compilation
But aside from the signer issue, for now you may need to deploy the implementation and proxy contracts directly (using ERC1967Proxy.sol or TransparentUpgradeableProxy.sol) until we add the proposed option.
@ericglau thanks for investigating, yeah the deployer issue was a bug on my end.
Summary:
I encountered an error while using the
@openzeppelin/hardhat-upgrades@2.3.3
plugin'sdeployProxy
function. The error arises when I use aContractFactory
created directly with the ABI and Bytecode, whereas usinggetContractFactory
works correctly.Details:
Initial Problem:
deployProxy
function from@openzeppelin/hardhat-upgrades
, I received the following error:Setup:
6.4.0
.2.19.0
Working Alternative:
getContractFactory
, the error doesn't appear and everything works as expected:attach
method on theContractFactory
:Current Status:
ethers@6.7.0
, usinggetContractFactory
works flawlessly.ContractFactory
directly with ABI and Bytecode (as shown above) still results in the aforementioneddeployProxy
error.Steps to Reproduce:
ethers@6.7.0
andhardhat@2.19.0
.@openzeppelin/hardhat-upgrades
plugin.deployProxy
function.Expected Behavior:
Both methods of creating a
ContractFactory
(direct ABI/Bytecode instantiation and usinggetContractFactory
) should work seamlessly with thedeployProxy
function without any errors.