No node with id 645 of type ContractDefinition

Support Upgrades
1

I get a "No node with id 645 of type ContractDefinition" error when I try to call deployProxy in migration if my repository has a contract inherited from DefaultOperatorFilterer.

If there is no such contract, or if inheritance is removed, then the error disappears.

My output:

truffle(develop)> migrate

Compiling your contracts...

===========================

> Compiling @openzeppelin\contracts-upgradeable\access\OwnableUpgradeable.sol

> Compiling @openzeppelin\contracts-upgradeable\proxy\utils\Initializable.sol
> Compiling @openzeppelin\contracts-upgradeable\utils\AddressUpgradeable.sol
> Compiling @openzeppelin\contracts-upgradeable\utils\ContextUpgradeable.sol
> Compiling .\contracts\Box.sol
> Compiling .\contracts\Vox.sol
> Compiling operator-filter-registry\src\DefaultOperatorFilterer.sol
> Compiling operator-filter-registry\src\IOperatorFilterRegistry.sol
> Compiling operator-filter-registry\src\OperatorFilterer.sol
> Compiling operator-filter-registry\src\lib\Constants.sol

> Artifacts written to D:\workspace\projects\test\build\contracts

> Compiled successfully using:
   - solc: 0.8.19+commit.7dd6d404.Emscripten.clang




Starting migrations...
======================
> Network name:    'develop'
> Network id:      5777
> Block gas limit: 6721975 (0x6691b7)


1-box.js
========


Exiting: Review successful transactions manually by checking the transaction hashes above on Etherscan.




Error: No node with id 645 of type ContractDefinition
    at deref (D:\workspace\projects\test\node_modules\@openzeppelin\upgrades-core\src\ast-dereferencer.ts:38:11)
    at curried (D:\workspace\projects\test\node_modules\@openzeppelin\upgrades-core\src\utils\curry.ts:13:14)
    at getInheritedContractOpcodeErrors (D:\workspace\projects\test\node_modules\@openzeppelin\upgrades-core\src\validate\run.ts:398:34)
    at getInheritedContractOpcodeErrors.next (<anonymous>)
    at getContractOpcodeErrors (D:\workspace\projects\test\node_modules\@openzeppelin\upgrades-core\src\validate\run.ts:291:10)     
    at getContractOpcodeErrors.next (<anonymous>)
    at getOpcodeErrors (D:\workspace\projects\test\node_modules\@openzeppelin\upgrades-core\src\validate\run.ts:266:10)
    at getOpcodeErrors.next (<anonymous>)
    at validate (D:\workspace\projects\test\node_modules\@openzeppelin\upgrades-core\src\validate\run.ts:204:14)
    at validateArtifacts (D:\workspace\projects\test\node_modules\@openzeppelin\truffle-upgrades\src\utils\validations.ts:21:18)    
    at getDeployData (D:\workspace\projects\test\node_modules\@openzeppelin\truffle-upgrades\src\utils\deploy-impl.ts:41:23)        
    at deployProxyImpl (D:\workspace\projects\test\node_modules\@openzeppelin\truffle-upgrades\src\utils\deploy-impl.ts:64:22)      
    at deployProxy (D:\workspace\projects\test\node_modules\@openzeppelin\truffle-upgrades\src\deploy-proxy.ts:36:26)
    at module.exports (D:\workspace\projects\test\migrations\1-box.js:5:3)

:1234: Code to reproduce

I have prepared a minimal repository that reproduces this: https://github.com/dmitry537/deploy-proxy-test

:computer: Environment

Ganache v7.8.0
Solidity - 0.8.19 (solc-js)

Node v18.16.0
Web3.js v1.10.0

Windows 10

help me please...

2

I tried on another computer with Windows 10 and the problem reproduced

3

This does not happen with hardhat.

4

I also recorded a video where you can see that the error disappears if you remove the contract with the DefaultOperatorFilterer from the repository. Can anyone explain what's going on?

5

Apologies for the delay.

I looked into this and I think I've identified the issue.

The root of the issue is a limitation of Truffle: it doesn't make the entire compiler output available so our Truffle Upgrades Plugin has to make an effort to reconstruct it based on the available information. In some cases there can be conflicting pieces of information so we have to try to detect those cases and delete the conflicting information. In this case we are wrongly deleting the AST for the DefaultOperatorFilterer contract and that is why it fails.

I can't guarantee that we will fix this soon, but in general due to this limitation of Truffle I would encourage you to use the Hardhat plugin instead. It is more powerful in general because Hardhat makes the full compiler output available to us.

6

I've opened an issue: