Truffle: Artifacts are from different compiler runs

I have upgraded to the latest version of the truffle upgrades package, version 1.2.3 as suggested. I still get this error when trying to run tests or deploy my contracts locally:

Error: Artifacts are from different compiler runs Run a full recompilation using truffle compile --all https://zpl.in/upgrades/truffle-recompile-all at reconstructSolcInputOutput (/Users/@openzeppelin/truffle-upgrades/src/validate.ts:70:15) at Object.validateArtifacts (/Users/@openzeppelin/truffle-upgrades/src/validate.ts:17:29)

I used the command truffle compile --all and it still gives this error.

Any help would be appreciated.

1 Like

@elliot Are you running on Windows? Please share more details about your project, and we will try to reproduce the error. If there is a repo you can share that is ideal.

You may want to take a look at Artifacts are from different compiler runs MacOS Node 14. We found an issue that I’m about to release a fix for.

2 Likes

I am running on a mac. I checked out that issue you linked. It seems like there is a single contract that is imported into two different files.

File A, B, C

The first file A, imports the contract C and directly inherits it.

The second file B, imports the first file A.

I’m thinking the issue is that maybe C is getting compiled twice once in file A, and then again in file B

This is the repo and branch I am running things from: https://github.com/Sifchain/sifnode/pull/270

1 Like

@elliot I was not able to run your tests because I’m missing all environment variables and I’m not sure what would be appropriate values.

Please try the version 1.2.4 of the Truffle plugin which was just released. It fixes the issue reported in Artifacts are from different compiler runs MacOS Node 14.

2 Likes

I guessed some values for the environment variables and was able to run the tests.

1 Like

I upgraded to version 1.2.4 and now I am getting this error deploying the oracle contract:

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:157:11) at Object.assertUpgradeSafe (/node_modules/@openzeppelin/upgrades-core/src/validate.ts:195:26) at deployProxy (/node_modules/@openzeppelin/truffle-upgrades/src/deploy-proxy.ts:33:3) at process._tickCallback (internal/process/next_tick.js:68:7)

Truffle v5.1.45 (core: 5.1.45) Node v10.20.1
This contract is in the build folder. In order to run the test, cd into the smart-contracts directory, cp .env.example. .env, run yarn develop in another window then run truffle test --network develop

1 Like

In the migrations file, all of the deployments set unsafeAllowCustomTypes: true so it should not be an issue that the solidity code uses structs and enums.

1 Like

Okay, I’m still not able to reproduce. I’ll ask a few questions to try to get a better idea of what’s going on.

Can you check if the code in the branch is up to date with what you’re running locally?

What contract is it?

Can you tell me if when you run truffle test you see a message from Truffle that says:

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

I can push up the changes to package.json to bump from version 1.2.3 --> 1.2.4, but that is the only difference from my local machine vs what is on the branch. Just pushed this change up so it should be 100% the same across branches.

The contract is Oracle.sol

Did you try running truffle test --network develop? That’s the way we run it locally.

1 Like

Yes I’m using that command.

I think I know what’s going on. There seems to be a typo in one of your files but you must be running on a case insensitive file system.

Please change the following in smart-contracts/contracts/BridgeBank/BridgeBank.sol.

 import "./CosmosBank.sol";
 import "./EthereumBank.sol";
-import "./EthereumWhiteList.sol";
+import "./EthereumWhitelist.sol";
 import "./CosmosWhiteList.sol";
 import "../Oracle.sol";
 import "../CosmosBridge.sol";
2 Likes

Thank you so much for taking the time help resolve this issue. That fix worked!

1 Like

Awesome. You’re welcome! I’ll see what we can do to fix this in the plugins.

2 Likes