Getting contract deploy error even though deploy was successful ("The contract code couldn't be stored, please check your gas limit")

[mckapur]

I'm on beta.33, and I'm seeing an issue where I deploy a contract and -- even though the contract successfully deployed -- I'll get an error saying: "The contract code couldn't be stored, please check your gas limit".

[travs]

the same for me with beta.34, but it only occurs with very large contracts (small contract deploy without this error). Actually I'm not totally sure that my large contract deploys, but it does get this error

[CryptoKiddies]

I'm seeing the same error on beta.26, which means it's definitely an unresolved issue with the 'error' promievent. It's quite intermittent though.

[nivida]

Could you please add your code for better understanding? @mckapur

[spalladino]

Same here, I'm on 0.20.6. I'll try to come up with a minimal example for reproducing it. It seems to happen more frequently when using Infura.

[spalladino]

I've written a small script to try to figure out the cause. I'm basically repeatedly calling getTransactionRecepit in a loop, followed by getCode of the receipt.contractAddress, much as contracts#checkForContractAddress does.

When running the script against a local node, the result is as expected: no tx receipt is returned from the getTransactionReceipt call, until a certain point where the code is successfully fetched:

[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got code:  0x60806040
[filter] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040

However, when running the script on Infura (mainnet), the result is not that consistent, and takes several seconds until it stabilizes:

[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got no receipt (returning)
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got empty code:  0x
[loop] Got empty code:  0x
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got no receipt (returning)
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got empty code:  0x
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040

Note that the Got empty code line happens in the script when code.length < 3, which is the condition that triggers the "The contract code couldn't be stored, please check your gas limit" error in web3's contract.js: https://github.com/ethereum/web3.js/blob/develop/lib/web3/contract.js#L145-L147

I'm not sure about the best fix for this, but instead of relying on getCode, shouldn't it be best to check the status field of the tx receipt? Or at least not to fail right away as the first empty code is returned.

[spalladino]

FWIW, the trace using Infura on Ropsten is quite consistent. I could only reproduce this on mainnet so far.

[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got no receipt (returning)
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040
[loop] Got code:  0x60806040

[captnseagraves]

Any word on the comment above @nivida? Building a project at Gitcoin and having issues with this. No solution found on the web works, but an intermittent error response with a consistent successful contract deployment on Rinkeby seems to fit. Using 1.0.0-beta.36.

[captnseagraves]

I've found a seeming fix. I had omitted gasPrice from .send() after .deploy() since the docs say it is optional. This made the gasPrice default to 1 wei, which seems to be an issue for Rinkeby. I declared gasPrice: 4000000000 and have stopped experiencing the intermittent errors from web3.js. Takeaway: listing a gasPrice param is not optional.

[KKnight99]

I'm seeing the same error on beta.36，when I deploy a larger contract, I will encounter this issue that the contract can not be deployed successfully because the status is 0x0 which is returned by the transaction. And I compared with the version of web3j which is a java version, it can deploy the same contract at the same time. So I think it is a bug for web3.js version to deploy contracts. Any body can help to fix it? Thanks.

[owocki]

@joshstevens19 @nivida hi from Gitcoin! Do you mind if we put a bounty on this to get some extra 👀 on it? we'd happily fund it, we rely on web3js for quite a bit :)

[nivida]

@owocki I'm in the middle of the refactoring and currently writing all the tests. Because of this, it should be done against the ethereumProvider branch but I think it's too early. I'm already in contact with Scott Moore and I sent him some bounties I know that they could be done without relying on the ongoing refactoring.

Bounty issues: https://github.com/ethereum/web3.js/issues?q=is%3Aopen+is%3Aissue+label%3Abounty

[nivida]

@captnseagraves Sorry for that. I will do this with priority 1 after I merged the ethereumProvider branch. I have to write 300+ tests and to be sure all behaviors are the same as described in the documentation. If you're interested in the ongoing refactoring please have a look at the PR #2000.

I give my best to be as fast as possible.

[captnseagraves]

@nivida No worries. We have a work-around in the meantime. For anyone else who lands here before the fixes are submitted I found this to work regardless if the error is present or not:

            myContract.deploy({
              data: bytecode,
              arguments: args
            }).send({
              from: xxx,
              gas: xxx,
              gasPrice: xxx
            }).on('error', function(error) {
              console.log('1', error);
            }).on('transactionHash', function(transactionHash) {
              console.log('2', transactionHash)

              var callFunctionWhenTransactionMined = function(transactionHash) {
                web3.eth.getTransactionReceipt(transactionHash, function(error, result) {
                  if (result) {
                    callSomeFunction(result);
                  } else {
                    setTimeout(function() {
                      callFunctionWhenTransactionMined(transactionHash);
                    }, 1000);
                  }
                });
              };
            callFunctionWhenTransactionMined(transactionHash);
          });

Excited to have this patch come through! Thanks nivida!

[UnclePetros]

@captnseagraves Thank you for your patch.
It works almost like a charm.
Sometimes when it goes in the error branch path, my node app crashed, even though result is returned correctly (my app is a rest api microservice).

[captnseagraves]

@UnclePetros Hmm, I haven't had my application crash due to the error path being triggered. We are using a Django backend, perhaps Node has a reaction to the javascript error that we do not experience.

You could try removing

           .on('error', function(error) {
             console.log('1', error);
           })

to see if that helps work around?

[nivida]

I've tested the contract deployment extensively with the latest release of Web3.js (beta.50) and didn't have any issue with it. Please open a new issue if I'm wrong.