truffle compile compiled migration contract to have lastCompletedMigration instead of last_completed_migration and it led to this error:
/usr/local/lib/node_modules/truffle/lib/migrate.js:226
migrations.last_completed_migration.call().then(function(completed_migration) {
^
TypeError: Cannot read property 'call' of undefined
at /usr/local/lib/node_modules/truffle/lib/migrate.js:226:42
at /usr/local/lib/node_modules/truffle/node_modules/ether-pudding/index.js:235:7
at tryToString (fs.js:425:3)
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:412:12)
I couldn't reproduce the bug on fresh project.
The compiled migration file should have last_completed_migration
It has lastCompletedMigration instead.
It turns out I used zeppelin to build up my contract and it has its own migration contract whose name exactly the same as truffle's migration contract. Thus it is replaced by zeppelin's one.
This is pretty tricky, I guess truffle should redesign the build/contracts directory structure so same name contracts don't replace each other.
Hi @tranvictor ! I'm facing the same issue. What did you do to solve it?
Thanks!
@JGcarv In my case, I just removed the redundant migration contract from zeppelin. See my comment above for better explanation 馃槃
I see. That makes sense. Thanks @tranvictor !
To clarify: Are all of you guys on Truffle 2? Truffle 3.x should fix this issue, as it has defined ordering of dependencies sources (i.e., your project first, then EthPM, then NPM). If you haven't yet, give Truffle 3.0 a try. It requires some upgrading, but you can find more information here: http://truffleframework.com/tutorials/upgrading-from-truffle-2-to-3
I'm going to close this ticket since it should be fixed in Truffle 3. If Truffle 3 users still have this issue, please reopen.
I can confirm that this issue persists in Truffle v3.2.7, and has screwed up my live net deployment. The Zeppelin Migrations contract, which I don't use, gets built and clobbers the Truffle Migrations contract.
The two are just similar enough that migrations can run, if the migrations contract has not yet been deployed, but then subsequent attempts to run migrations fail with the incredibly uninformative:
$ truffle migrate
Using network 'development'.
TypeError: Cannot read property 'call' of undefined
at <snip>\npm\node_modules\truffle\build\cli.bundled.js:54937:49
at process._tickCallback (internal/process/next_tick.js:109:7)
Truffle should fail at the compile step if two contracts have the same name, because it can't do anything other than clobber one with the other.
Alternately, "Truffle" should be sprinkled liberally throughout the migrations contract method names, to avoid giving the appearance of working when you have the wrong contract.
I'm seeing the same issue here
We were having this issue as well, it was temporarily fixed by removing all built contracts from their directory. There still appear to be several bugs in this catagory in the latest version of truffle regardless.
This should be reopened because is still an active issue. @tranvictor @tcoulter
My error on truffle migrate on Truffle v3.4.11 (core: 3.4.11):
Using network 'development'.
TypeError: Cannot read property 'call' of undefined
at C:\Users\mirko\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:72945:49
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7)
Sorry, my fault... I've updated my code and appear to be solved. Will update if it isn't.
I stumbled upon the same problem while trying to run truffle migrate.
I got around it by removing the build directory, restart Ganache. Afterward truffle migrate runs smoothly
truffle version
Truffle v4.0.4 (core: 4.0.4)
Solidity v0.4.18 (solc-js)
This problem happens after a previous migrate run caused Ganache to crash. For some reason the build was invalid and thus it was trying to read from the previous build is my assumption.
Anyway, cheer.
I am having this same issue with the error that @tranvictor got at the start, at the exact same line however, my contracts folder does not contain an additional migrations file (i.e. I just have the one), yet I still get the error at the module:
` lastCompletedMigration: function(options, callback) {
var Migrations;
try {
Migrations = options.resolver.require("Migrations");
} catch (e) {
return callback(new Error("Could not find built Migrations contract: " + e.message));
}
if (Migrations.isDeployed() == false) {
return callback(null, 0);
}
var migrations = Migrations.deployed();
Migrations.deployed().then(function(migrations) {
return migrations.last_completed_migration.call();
}).then(function(completed_migration) {
callback(null, completed_migration.toNumber());
}).catch(callback);
},`
The line that throws is:
return migrations.last_completed_migration.call();
However, in the Migrations.json file, the function reads:
{
"constant": true,
"inputs": [],
"name": "lastCompletedMigration",
"outputs": [
{
"name": "",
"type": "uint256"
}
],
Meaning the method last_completed_migration is not being found as there is one named lastCompletedMigration. Where would this be? Is there a way of altering the migrations folder to specifically call this instead?
This is absolutely vital to be able to deploy large sets of contracts which are inter-linked as you cannot expect people to risk spending $100 on every migration to deploy them all together and as it stands, you cannot migrate contracts separately using truffle due to this error.
@JackPickering Could you update to the latest Truffle and test with that? The current migrations logic looks like this:
Migrations.deployed().then(function(migrations) {
// Two possible Migrations.sol's (lintable/unlintable)
return (migrations.last_completed_migration)
? migrations.last_completed_migration.call()
: migrations.lastCompletedMigration.call();
}).then(function(completed_migration) {
callback(null, completed_migration.toNumber());
}).catch(callback);
It looks like you're trying to run a newer version of the migrations contract with an older version of truffle which doesn't support it.
I've updated to Truffle @4.1.3
Then ran 'truffle unbox webpack'
This is my migrations.sol contract...
pragma solidity ^0.4.17;
contract Migrations {
address public owner;
uint public last_completed_migration;
modifier restricted() {
if (msg.sender == owner) _;
}
function Migrations() public {
owner = msg.sender;
}
function setCompleted(uint completed) public restricted {
last_completed_migration = completed;
}
function upgrade(address new_address) public restricted {
Migrations upgraded = Migrations(new_address);
upgraded.setCompleted(last_completed_migration);
}
}
This is my migrations.js file...
var Migrations = artifacts.require("./Migrations.sol");
module.exports = function(deployer) {
deployer.deploy(Migrations);
};
Where is this new logic meant to be?
@JackPickering The new logic is at truffle-migrate where the migrations are processed. There are now two possible versions of the standard migrations contract - the original and a newer one that follows the Solidity style guidelines and camel cases the variable names. It's installed when anyone starts a new project from scratch with truffle init.
The ABI you showed indicates the compiled contract you're interacting with is the newer version:
{ "constant": true, "inputs": [], "name": "lastCompletedMigration", "outputs": [ { "name": "", "type": "uint256" } ],
Is Petshop the project you're working on?
Okay, that makes sense thank you, its worked but now I get a different error unrelated to this thread. Myabe you could help though if you wouldnt mind? It basically now says Error: Could not setnullas the transaction hash for SaleStagesLib when I try to link a library that has already been migrated.
https://github.com/trufflesuite/truffle-migrate/issues/24
Much appreciated,
Thanks
Most helpful comment
I stumbled upon the same problem while trying to run
truffle migrate.I got around it by removing the
builddirectory, restart Ganache. Afterwardtruffle migrateruns smoothlyThis problem happens after a previous migrate run caused
Ganacheto crash. For some reason the build was invalid and thus it was trying to read from the previous build is my assumption.Anyway, cheer.