Truffle: Truffle v5 preFlightCheck error after clean compile when testing

[NoahZinsmeister]

• [x] I've asked for help in the Truffle Gitter before filing this issue.

Issue

After running a clean truffle compile, running truffle test gives a Deployer._preFlightCheck error. However, by saving one or more contract files after building, so that the test command triggers a re-compile before running, temporarily fixes the issue. For example, the tests run successfully after running touch on any file in the contracts/ folder.

Steps to Reproduce

This error is reproducible:

• git clone https://github.com/hydrogen-dev/ERC-1484.git
• cd ERC-1484
• git checkout 983befd
• npm install
• npm run build
• In one terminal tab: npm run chain
• In another: npm run test

Expected Behavior

The tests to successfully run.

Actual Results

    at Deployer._preFlightCheck (/Users/noahzinsmeister/Documents/test/ERC-1484/node_modules/truffle/build/webpack:/packages/truffle-deployer/src/deployment.js:181:1)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Environment

• Operating System: macOS High Sierra 10.13.6 (17G65)
• Ethereum client: Ganache CLI v6.1.8 (ganache-core: 2.2.1)
• Truffle version (truffle version): Truffle v5.0.0-beta.1 (core: 5.0.0-beta.1)
• node version (node --version): v10.10.0
• npm version (npm --version): 6.4.1

[NoahZinsmeister]

So, I tracked down the bug. In line 231 of index.js in truffle-compile, interfaces/contracts defined in source .sol files are written to a returnVal object. However, if the same contract/interface name exists in multiple source files, the last contract/interface with the same name to be processed is the only that is saved, because previous values are overwritten. This leads to severe data corruption.

This bug has been frustrating, I'd be happy to provide further details or a dummy example so that this can get fixed (cc @CruzMolina let me know if there's anything I can do to help).

[paulrberg]

In my case, this occurred when I mistakenly prevented the Migrations contract from being deployed.

Update: not only that, but when a contract conforming to an interface doesn't implement all the methods properly. Truffle gives you more information when running the migrations normally.

[msrobot0]

So, I tracked down the bug. In line 231 of index.js in truffle-compile, interfaces/contracts defined in source .sol files are written to a returnVal object. However, if the same contract/interface name exists in multiple source files, the last contract/interface with the same name to be processed is the only that is saved, because previous values are overwritten. This leads to severe data corruption.

This bug has been frustrating, I'd be happy to provide further details or a dummy example so that this can get fixed (cc @CruzMolina let me know if there's anything I can do to help).

Hi I have been getting that recently too - can you give me any tips -thanks

[eggplantzzz]

Thanks for raising this issue. The namespacing issue is something we're aware of and will be working on a solution for in the future. Stay tuned!

[NoahZinsmeister]

thanks @eggplantzzz!

[jochenonline]

Can confirm that the problem vanishes if double contract names are prevented. Which is of course annoying if a contract uses another contract. In that case I have to use different contract names each time a contract is referenced.

[CosminNechifor]

Happened to me as well while doing refactoring, because I left one of the contracts constructor internal. When a contract constructor is internal it will make the contract an Abstract Contact which can't be compiled. Hope this will help someone.

[alanduw]

Hello!

I would like to add one more case in addition to the following comment (One under Update, to be precise):

In my case, this occurred when I mistakenly prevented the Migrations contract from being deployed.

Update: not only that, but when a contract conforming to an interface doesn't implement all the methods properly. Truffle gives you more information when running the migrations normally.

Introduction

I was doing some reorganization inside my contracts directory. We know, that in case one has a following contract _A_:

contract A { uint public thisOne; }

then the Solidity compiler would generate a default getter of the external visibility for this public state variable.

And it would be totally fine to create an interface (_InterfaceA_) that contract _A_ would later implement in order to conveniently expose it to the other contracts:

interface InterfaceA {
    function thisOne() external view returns (uint);
}

contract A is InterfaceA {
    uint public thisOne;
}

At this point remix IDE (0.5.1+commit.c8a2cb62.Emscripten.clang) had no problems with that.

Problem

But not [remix IDE (0.5.0+commit.1d4f565a.Emscripten.clang)](https://remix.ethereum.org/#optimize=false&version=soljson-v0.5.0+commit.1d4f565a.js)

I got this Truffle error as a result of wrong Solidity compiler version:
`

Compiled successfully using:
- solc: 0.5.0+commit.1d4f565a.Emscripten.clang
Error at Deployer._preFlightCheck (/mnt/c/Users/.../contracts/node_modules/truffle/build/webpack:/packages/truffle-deployer/src/deployment.js:178:1)
Truffle v5.0.8 (core: 5.0.8)
Node v11.8.0

Solution

In this case Truffle had nothing to do with this, but following suggestions could help someone:

1. Make the interface, but do not implement it in the contract you wanted to. Only use it from other contracts (not a good development pattern, though).
2. Do not rely on the default getter and make the getter yourself. Declare it in the interface. In this case the interface can be implemented by the contract (extra gas used on the deployment).
3. Truffle v5 comes with an amazing feature Bring your own compiler!. According to my experiments, the Solidity compiler started working correctly (definitely) with the version 0.5.1+commit.c8a2cb62.Emscripten.clang (should be fine enough).

[Alexangelj]

Hi, still having this issue with using two npm packages: @openzeppelin/contracts and openzeppelin-solidity. Is there a workaround or a fix that does not include renaming contracts so there are no duplicates?

[k06a]

Have the same issue

[michaelcohen716]

+1
Is there a best practice yet for addressing this bug?
Recommendations/hacks above do not work for me

[eggplantzzz]

We've had it in the pipeline to fix this issue for a long time but it is not trivial. I'm not sure when to expect a fix for this but it is coming!

[gnidan]

Is this still a problem? Thanks!

[gnidan]

Closing this for issue maintenance, but let us know if there's more to do here, and we'll gladly re-open to re-visit. Thanks!