Truffle discards all (potentially expensive) deployed contracts when a migration fails

[interfect]

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

---

Issue

Truffle doesn't save the addresses of contracts successfully deployed during failed migrations to build/contracts/*.json. This means it is very difficult/impossible to re-use those already-paid-for contract deployments when re-running the migration.

Steps to Reproduce

• Make a migration that deploys 2 contracts.
• Give it only enough ETH to pay for one deployment.
• Run the migration on the live network, so it deploys the first contract and does not deploy the second.
• Look at the file for the deployed contract in build/contracts.
• Note the absence of any address for the contract on the mainnet.
• Verify with a block explorer that the contract is actually deployed.

Expected Behavior

The address that the contract is deployed to ought to be saved to its file in build/contracts as soon as it is deployed, so that re-running the migration with {replace: false} could, at least for simple migrations, potentially recover from the failure.

Actual Results

The address that the contract is deployed at on the main network is not saved to the file in build/contracts.

Environment

• Operating System: Windows 7
• Truffle version: 3.2.92
• Ethereum client: Geth
• node version: 1.6.5
• npm version: 4.2.0

[Janther]

I'm experiencing the same issue in all networks, even testrpc.

[tcoulter]

When a migration fails, it's often hard figuring out what happened. We working on two ways to make migrations better that, when used correctly, should prevent the error you're seeing here.

1. Migrations should show hashes of all transactions attempted. #495 - Show all transactions that were attempted during a migration. This should give you more information about what happened and allow you to diagnose your migration.
2. Integrate TestRPC with Truffle #490 - Integrate the TestRPC into Truffle, and include a --dry-run feature that will fork from your desired chain and deploy your migrations in a sandbox, as if you were deploying them on the chain itself.

With (2), you should be able to use --dry-run to expose migration errors more quickly. With (1), you should be able to diagnose those errors to see what happened during those transactions.

I'm going to close this ticket as the two tickets above will track our progress on this issue. Please stay tuned for these new features as they're added.