deployProxy() using `truffle migrate --reset` errors with requested contract was not found

Support Upgrades
#1

In my migraton I am using the same artifact that works with await deployer.deploy() than deployProxy().

But with deployProxy() when I run truffle migrate --reset` I get the following error:

`Error: The requested contract was not found. Make sure the source code is available for compilation
at getContractNameAndRunValidation (…/node_modules/@openzeppelin/upgrades-core/src/
validate.ts:159:11)

$ truffle version
Truffle v5.1.60 (core: 5.1.60)
Solidity - 0.5.11 (solc-js)
Node v10.23.1
Web3.js v1.2.9
1 Like
OpenZeppelin Upgrades: Step by Step Tutorial for Truffle
#2

Hi @ccolorado,

Are you able to share the full output from truffle migrate?

What commands had you previously run, e.g. truffle migrate?
What network are you deploying to? Were you doing a dry run?

I wasn’t able to reproduce unfortunately. I did the following:

  1. $ npx truffle migrate --network rinkeby
  2. $ npx truffle migrate --network rinkeby --reset
$ npx truffle migrate --network rinkeby --reset

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.



Starting migrations...
======================
> Network name:    'rinkeby'
> Network id:      4
> Block gas limit: 10000000 (0x989680)


1_initial_migration.js
======================

   Replacing 'Migrations'
   ----------------------
   > transaction hash:    0xaa96fe2dadeaf19f4196fe08c8df771f6b7925fab9ab9de4796d970d67b84fcb
   > Blocks: 1            Seconds: 9
   > contract address:    0xDc4A551e0AfBA493246149B1B7ea6Aaa1F9fC7BC
   > block number:        7874819
   > block timestamp:     1610349951
   > account:             0xEce6999C6c5BDA71d673090144b6d3bCD21d13d4
   > balance:             7.283331938
   > gas used:            186951 (0x2da47)
   > gas price:           10 gwei
   > value sent:          0 ETH
   > total cost:          0.00186951 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00186951 ETH


2_deploy_box.js
===============

   Deploying 'AdminUpgradeabilityProxy'
   ------------------------------------
   > transaction hash:    0xf24339e64957244386ed57191b44733402234094161cdb601eb2c644e9ec72d1
   > Blocks: 1            Seconds: 9
   > contract address:    0xD13cA5dc87820844e6f34f84E590B62153AB8A95
   > block number:        7874823
   > block timestamp:     1610350011
   > account:             0xEce6999C6c5BDA71d673090144b6d3bCD21d13d4
   > balance:             7.276701938
   > gas used:            620665 (0x97879)
   > gas price:           10 gwei
   > value sent:          0 ETH
   > total cost:          0.00620665 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00620665 ETH


Summary
=======
> Total deployments:   2
> Final cost:          0.00807616 ETH

I am running on WSL2 on Windows 10

$ npx truffle version
Truffle v5.1.61 (core: 5.1.61)
Solidity - 0.7.5 (solc-js)
Node v10.22.1
Web3.js v1.2.9
1 Like
#3

Hi @abcoathup. Thanks for taking the time to check my question.

So I dug into the openzeppelin’s upgrades-core && truffle-upgrades.

Found out that there are some scenarios that can cause a contract source to be discarded from the migration candidates. (In hindsight It would be useful to have these scenarios produce some kind of error)

After doing some tweaking on my contract I was able to get past that error. but ended up seeing errors like these.

Now I have already deployed contracts with @openzeppelin/cli. Which does not enforce validations (or at least it didn’t at the time I used it).

Have you guys published the risks of not moving to @openzeppelin/truffle-upgrades?

UPDATE:,
There seems to be a bug on how the input and output objects are populated checkForImportIdConsistency. Submitted the following issue.

1 Like
#4

Hi @ccolorado,

OpenZeppelin CLI included upgrade safety checks.

Now that CLI support has ended (see: Building for interoperability: why we’re focusing on Upgrades Plugins), I would recommend migrating to the Upgrades Plugins. Primarily to benefit from the tooling for test and deployment, including the upgrade safety checks. Also to avoid using a project that is no longer supported.

I wasn’t able to reproduce the error in https://github.com/OpenZeppelin/openzeppelin-upgrades/issues/279 (yet) but we can continue that discussion in the issue.

1 Like
#5

Hi @ccolorado,

An issue has been created to allow skipping specific upgrade safety checks.

1 Like