web3.js v1.0.0-beta.30 send() - Error: Failed to check for transaction receipt:

[netkiller]

my version is 1.0.0-beta.30

console.log(web3.version)
1.0.0-beta.30

my program is the follow code.

`
fs = require('fs');
var net = require('net');
var Web3 = require('web3');
var web3 = new Web3('/Users/neo/Library/Ethereum/geth.ipc', net); // to connect roosten network

console.log(web3.version)
const abi = fs.readFileSync('output/TokenERC20.abi', 'utf-8');

const contractAddress = "0x70682386d0dE84B1e549DC3c4305CCB2D261b2a8";
const coinbase = "0xB94054c174995AE2A9E7fcf6c7924635FBa8ECF7";
const toAddress = "0xf56b81a2bcb964D2806071e9Be4289A5559BB0fA";

balanceWei = web3.eth.getBalance(coinbase);
console.log(balanceWei);

const contract = new web3.eth.Contract(JSON.parse(abi), contractAddress, { from: coinbase , gas: 100000});

web3.eth.personal.unlockAccount(coinbase, "netkiller").then(function(result){
console.log(result)
contract.methods.balanceOf(coinbase).call().then(console.log).catch(console.error);
contract.methods.balanceOf(toAddress).call().then(console.log).catch(console.error);
});

contract.methods.transfer(toAddress, 10000).send().then(function(receipt){

console.log(receipt);

}).catch(console.error);

contract.methods.balanceOf(coinbase).call().then(console.log).catch(console.error);
contract.methods.balanceOf(toAddress).call().then(console.log).catch(console.error);

`

when I execute send() " Error: Failed to check for transaction receipt: "

`

contract.methods.transfer(toAddress, 10000.00).send().then(function(receipt){
...
... console.log(receipt);
...
... }).catch(console.error);
Promise {
_bitField: 0,
_fulfillmentHandler0: undefined,
_rejectionHandler0: undefined,
_promise0: undefined,
_receiver0: undefined }
Error: Failed to check for transaction receipt:
{}
at Object._fireError (/Users/neo/ethereum/web3/node_modules/web3-utils/src/index.js:56:17)
at /Users/neo/ethereum/web3/node_modules/web3-core-method/src/index.js:259:23
at bound (domain.js:375:14)
at runBound (domain.js:388:12)
at tryCatcher (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:497:31)
at Promise._settlePromise (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:555:18)
at Promise._settlePromise0 (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:600:10)
at Promise._settlePromises (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:679:18)
at Async._drainQueue (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/async.js:125:16)
at Async._drainQueues (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/async.js:135:10)
at Immediate.Async.drainQueues (/Users/neo/ethereum/web3/node_modules/web3-core-promievent/node_modules/bluebird/js/release/async.js:16:14)
at runCallback (timers.js:763:18)
at tryOnImmediate (timers.js:734:5)
at processImmediate (timers.js:716:5)
at process.topLevelDomainCallback (domain.js:101:23)
`

[CodingJonas]

I have the same error while deploying a contract, using the same version of web3.
I tried to follow the official documentation as close as possible:

var Web3 = require('web3')
var NodeHandle = require('./nodeHandle.js')
let fs = require('fs');
let source = fs.readFileSync("./contracts.json");
let contract_from_file = JSON.parse(source)["contracts"]['helloWorld.sol:HelloWorld'];
// Get important information from contract
const ABI = JSON.parse(contract_from_file.abi);
const CODE = '0x' + contract_from_file.bin;
const OWNER_ADDRESS = nodeHandle.address;

// helper function to receive the proper web3 node
web3 = nodeHandle.getWeb3NodeAPI();

const myContract = new web3.eth.Contract(ABI);

let options = {
    from: OWNER_ADDRESS,
    gas: 1500001,
    gasPrice: '30000000000000' // How do I get gas and gasPrice
}

console.log("Contract gets deployed, this can take a while...");
myContract.deploy({
    data: CODE
})
    .send(options)
    .on('error', function (error) { console.log("ERROR: ", error.message); })
    .on('transactionHash', function (transactionHash) { console.log("TransactionHash: " + transactionHash); })
    .on('receipt', function (receipt) {
        console.log("Receipt: " + receipt.contractAddress); // contains the new contract address
    })
    .then(function (newContractInstance) {
        console.log("Address: " + newContractInstance.options.address); // instance with the new contract address
    });

This returns:

Contract gets deployed, this can take a while...
TransactionHash: 0xadf571aa3a8b7f086d84c749700fb144846008a03cd3a6baa7dbd83e57a6e086
ERROR:  Failed to check for transaction receipt:
{}
Unhandled rejection Error: Failed to check for transaction receipt:
{}
    at Object._fireError (/Users/jNa/Blockchain/scripts/node_modules/web3-utils/src/index.js:56:17)
    at /Users/jNa/Blockchain/scripts/node_modules/web3-core-method/src/index.js:259:23
    at tryCatcher (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:497:31)
    at Promise._settlePromise (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:555:18)
    at Promise._settlePromise0 (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:600:10)
    at Promise._settlePromises (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/promise.js:679:18)
    at Async._drainQueue (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/async.js:125:16)
    at Async._drainQueues (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/async.js:135:10)
    at Immediate.Async.drainQueues (/Users/jNa/Blockchain/scripts/node_modules/web3-core-promievent/node_modules/bluebird/js/release/async.js:16:14)
    at runCallback (timers.js:763:18)
    at tryOnImmediate (timers.js:734:5)
    at processImmediate (timers.js:716:5)

Checking in a block explorer, I can see the contract was successfully deployed. Unfortunately I can't receive the address of the contract since the promise gets interrupt due to the (wrong?) error.

Does anyone know a solution or a workaround to receive the contract address?

[saniales]

:+1:

[erinbagel]

@CodingJonas not sure if you're using ropsten as well (I am using a private net on geth), but the contract address should be showing in your geth console. There needs to be a way to grab this value on the front end, as I am successfully getting the transaction hash. Not sure why receipt or receipt.contractAddress isn't working.

it looks like you are missing the .on('confirmation') check, but it is not working for me. I have this:
.send({ from: OWNER ADDRESS, gas: 1500000, gasPrice: myGasPrice }, function(error, transactionHash){ if(error){ console.log("error function: " + error.message) } else { console.log("transaction hash:" + transactionHash) } }) .on('error', function(error){ console.log("error on send: " + error.message) }) .on('transactionHash', function(transactionHash){ console.log("Transaction Hash" + transactionHash)}) .on('receipt', function(receipt){ console.log("New receipt: " + receipt.contractAddress) }) .on('confirmation', function(confirmationNumber, receipt){ console.log(confirmationNumber) console.log(receipt)}) .then(function(newContractInstance){ console.log(newContractInstance.options.address) });``

Re: comment in your code: This is how I get gas price using promises:
const myGasPrice = Promise.await(web3.eth.getGasPrice());

[leon740727]

Hi, I have the same error and I fix it by #1735
ps. I am using web3.eth.sendSignedTransactio on websocket provider

[bj97301]

Is this fixed? I am not getting a confirmation callback when deploying my contract.

[bj97301]

I updated to beta 37 and it seems to work now 👯‍♀️

[d10r]

I'm seeing this in 1.2.1.
Happening with a local node running Parity 2.5.5, connected to a network with AuRa consensus. To me it looks like some kind of race condition which depends on some timing details of the connected RPC node.
E.g. I just had this:

> await web3.eth.sendTransaction( {value: 1, from: "0xCC2db9859Ebe5c917B80b6DC6d9E78393097e429", to: "0x6ccaA51F295652dC33F4d8ce12379eac3594f3D2" } )
Error: Failed to check for transaction receipt:
{}
    at Object._fireError (/home/didi/.nvm/versions/node/v10.14.2/lib/node_modules/web3/node_modules/web3-utils/src/index.js:56:17)
> await web3.eth.sendTransaction( {value: 1, from: "0xCC2db9859Ebe5c917B80b6DC6d9E78393097e429", to: "0x6ccaA51F295652dC33F4d8ce12379eac3594f3D2" } )
{ blockHash:
   '0xfe6fc8effcf1d378ac81ca0bb6a953be29eacf25fb0d5ceee6bb18719590b9e7',
  blockNumber: 4181476,
  contractAddress: null,
  cumulativeGasUsed: 21000,
  from: '0xcc2db9859ebe5c917b80b6dc6d9e78393097e429',
  gasUsed: 21000,
  logs: [],
  logsBloom:
   '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
  root: null,
  status: true,
  to: '0x6ccaa51f295652dc33f4d8ce12379eac3594f3d2',
  transactionHash:
   '0xba15dd40e85bc11a3ddfc53d2ca1afa783729fd8d7a9673d8ac70c4986a25e2d',
  transactionIndex: 0 }

The second command was issues a few seconds after the first one.

I'd guess that web3.js makes an assumption (e.g. that the receipt is available once the tx hash is known?) which doesn't always hold.

Unfortunately I didn't find a way to make it reproducible.

[cgewecke]

@d10r Thanks for reporting - this problem is being tracked as #1255, through #3070.

[d10r]

A bit more detail, maybe it helps...
I started the local Parity node with some logging enabled (-l rpc=trace,tx=trace). This was the output during the described failure:

2019-10-16 22:21:16  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":1,"method":"eth_gasPrice","params":[]}.
2019-10-16 22:21:16  jsonrpc-eventloop-1 DEBUG rpc  [Some(Num(1))] Took 11ms
2019-10-16 22:21:16  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x4190ab00","id":1}.
2019-10-16 22:21:16  jsonrpc-eventloop-0 TRACE rpc  Request: {"jsonrpc":"2.0","id":2,"method":"eth_sendTransaction","params":[{"value":"0x1","from":"0xcc2db9859ebe5c917b80b6dc6d9e78393097e429","to":"0x6ccaa51f295652dc33f4d8ce12379eac3594f3d2","gasPrice":"0x4190ab00"}]}.
2019-10-16 22:21:16  jsonrpc-eventloop-0 WARN rpc  eth_sendTransaction is deprecated and will be removed in future versions: Account management is being phased out see #9997 for alternatives.
2019-10-16 22:21:16  jsonrpc-eventloop-0 DEBUG txqueue  [0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53] Added to the pool.
2019-10-16 22:21:16  jsonrpc-eventloop-0 DEBUG txqueue  [0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53] Sender: 0xcc2d…e429, nonce: 306, gasPrice: 1100000000, gas: 1600000, value: 1, dataLen: 0))
2019-10-16 22:21:16  jsonrpc-eventloop-0 DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53","id":2}.
2019-10-16 22:21:16  IO Worker #1 DEBUG txqueue  Re-computing pending set for block: 4186006
2019-10-16 22:21:16  jsonrpc-eventloop-0 TRACE rpc  Request: {"jsonrpc":"2.0","id":3,"method":"eth_getTransactionReceipt","params":["0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53"]}.
2019-10-16 22:21:16  jsonrpc-eventloop-0 DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32000,"message":"Block information is incomplete while ancient block sync is still in progress, before it's finished we can't determine the existence of requested item."},"id":3}.
2019-10-16 22:21:17  jsonrpc-eventloop-0 TRACE rpc  Request: {"jsonrpc":"2.0","id":4,"method":"eth_getTransactionReceipt","params":["0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53"]}.
2019-10-16 22:21:17  jsonrpc-eventloop-0 DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32000,"message":"Block information is incomplete while ancient block sync is still in progress, before it's finished we can't determine the existence of requested item."},"id":4}.
2019-10-16 22:21:20  Verifier #4 TRACE txqueue  Refreshing certified addresses cache
2019-10-16 22:21:20  IO Worker #3 INFO own_tx  Transaction mined (hash 0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53)
2019-10-16 22:21:20  IO Worker #3 DEBUG txqueue  [0xa2ff0ed0a58118971c14750dc73c920b806bb23e336bfde159bc6a70e1173e53] Culled or mined.
2019-10-16 22:21:20  IO Worker #3 DEBUG txqueue  Removed 1 stalled transactions. Pool: 0/8192 (0 senders; 0/4096 kB) [minGasPrice: 1000 Mwei, maxGas: 8000000]

So, here the receipt was unavailable because ... ancient block sync is still in progress.
Thus I restarted the node with --no-ancient-blocks added to the cmdline.

This didn't eliminate the issue, but changed the error message:

2019-10-16 22:26:27  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":5,"method":"eth_gasPrice","params":[]}.
2019-10-16 22:26:27  jsonrpc-eventloop-1 DEBUG rpc  [Some(Num(5))] Took 23ms
2019-10-16 22:26:27  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x4190ab00","id":5}.
2019-10-16 22:26:27  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":6,"method":"eth_sendTransaction","params":[{"value":"0x1","from":"0xcc2db9859ebe5c917b80b6dc6d9e78393097e429","to":"0x6ccaa51f295652dc33f4d8ce12379eac3594f3d2","gasPrice":"0x4190ab00"}]}.
2019-10-16 22:26:27  jsonrpc-eventloop-1 WARN rpc  eth_sendTransaction is deprecated and will be removed in future versions: Account management is being phased out see #9997 for alternatives.
2019-10-16 22:26:27  jsonrpc-eventloop-1 DEBUG txqueue  [0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d] Added to the pool.
2019-10-16 22:26:27  jsonrpc-eventloop-1 DEBUG txqueue  [0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d] Sender: 0xcc2d…e429, nonce: 307, gasPrice: 1100000000, gas: 1600000, value: 1, dataLen: 0))
2019-10-16 22:26:27  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d","id":6}.
2019-10-16 22:26:27  IO Worker #0 DEBUG txqueue  Re-computing pending set for block: 4186058
2019-10-16 22:26:27  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":7,"method":"eth_getTransactionReceipt","params":["0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d"]}.
2019-10-16 22:26:27  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32000,"message":"Looks like you disabled ancient block download, unfortunately the information you're trying to fetch doesn't exist in the db and is probably in the ancient blocks."},"id":7}.
2019-10-16 22:26:28  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":8,"method":"eth_getTransactionReceipt","params":["0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d"]}.
2019-10-16 22:26:28  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32000,"message":"Looks like you disabled ancient block download, unfortunately the information you're trying to fetch doesn't exist in the db and is probably in the ancient blocks."},"id":8}.
2019-10-16 22:26:30  Verifier #6 TRACE txqueue  Refreshing certified addresses cache
2019-10-16 22:26:30  IO Worker #0 INFO own_tx  Transaction mined (hash 0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d)
2019-10-16 22:26:30  IO Worker #0 DEBUG txqueue  [0xe6e53393006ce5eed76d98f6edbe67801960b95f53d83556331afa906e12cb1d] Culled or mined.
2019-10-16 22:26:30  IO Worker #0 DEBUG txqueue  Removed 1 stalled transactions. Pool: 0/8192 (0 senders; 0/4096 kB) [minGasPrice: 1000 Mwei, maxGas: 8000000]

... which leads to https://github.com/paritytech/parity-ethereum/issues/10550

So, the Parity folks seem to be believe that the current behaviour is correct.

What I found interesting was that in both cases web3.js seemed to retry the eth_getTransactionReceipt call again after the first failure. However it did so without delay, thus it didn't make a difference.

Then I discovered and tried another cmdline option of parity: --jsonrpc-allow-missing-blocks. Which is documented like this: RPC calls will return 'null' instead of an error if ancient block sync is still in progress and the block information requested could not be found.
With that option in place, the problem seems to go away and the log output looks like this:

2019-10-16 22:42:23  jsonrpc-eventloop-0 TRACE rpc  Request: {"jsonrpc":"2.0","id":33,"method":"eth_gasPrice","params":[]}.
2019-10-16 22:42:23  jsonrpc-eventloop-0 DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x4190ab00","id":33}.
2019-10-16 22:42:23  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":34,"method":"eth_sendTransaction","params":[{"value":"0x1","from":"0xcc2db9859ebe5c917b80b6dc6d9e78393097e429","to":"0x6ccaa51f295652dc33f4d8ce12379eac3594f3d2","gasPrice":"0x4190ab00"}]}.
2019-10-16 22:42:23  jsonrpc-eventloop-1 WARN rpc  eth_sendTransaction is deprecated and will be removed in future versions: Account management is being phased out see #9997 for alternatives.
2019-10-16 22:42:23  jsonrpc-eventloop-1 DEBUG txqueue  [0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff] Added to the pool.
2019-10-16 22:42:23  jsonrpc-eventloop-1 DEBUG txqueue  [0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff] Sender: 0xcc2d…e429, nonce: 314, gasPrice: 1100000000, gas: 1600000, value: 1, dataLen: 0))
2019-10-16 22:42:23  jsonrpc-eventloop-1 DEBUG rpc  [Some(Num(34))] Took 20ms
2019-10-16 22:42:23  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff","id":34}.
2019-10-16 22:42:23  IO Worker #3 DEBUG txqueue  Re-computing pending set for block: 4186216
2019-10-16 22:42:23  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":35,"method":"eth_getTransactionReceipt","params":["0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff"]}.
2019-10-16 22:42:23  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":null,"id":35}.
2019-10-16 22:42:24  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":36,"method":"eth_getTransactionReceipt","params":["0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff"]}.
2019-10-16 22:42:24  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":null,"id":36}.
2019-10-16 22:42:25  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":37,"method":"eth_getTransactionReceipt","params":["0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff"]}.
2019-10-16 22:42:25  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":null,"id":37}.
2019-10-16 22:42:25  Verifier #1 TRACE txqueue  Refreshing certified addresses cache
2019-10-16 22:42:25  IO Worker #2 INFO own_tx  Transaction mined (hash 0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff)
2019-10-16 22:42:25  IO Worker #2 DEBUG txqueue  [0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff] Culled or mined.
2019-10-16 22:42:25  IO Worker #2 DEBUG txqueue  Removed 1 stalled transactions. Pool: 0/8192 (0 senders; 0/4096 kB) [minGasPrice: 1000 Mwei, maxGas: 8000000]

2019-10-16 22:42:25  Verifier #1 INFO import  Imported #4186217 0x23fb…1b77 (1 txs, 0.02 Mgas, 10 ms, 0.68 KiB)
2019-10-16 22:42:26  IO Worker #3 DEBUG txqueue  Re-computing pending set for block: 4186217
2019-10-16 22:42:26  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":38,"method":"eth_getTransactionReceipt","params":["0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff"]}.
2019-10-16 22:42:26  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":{"blockHash":"0x23fb50bf055491345509c712f68213579b05a357e6985e4f965e895144621b77","blockNumber":"0x3fe069","contractAddress":null,"cumulativeGasUsed":"0x5208","from":"0xcc2db9859ebe5c917b80b6dc6d9e78393097e429","gasUsed":"0x5208","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","root":null,"status":"0x1","to":"0x6ccaa51f295652dc33f4d8ce12379eac3594f3d2","transactionHash":"0xc29f84952e426c993e0d7cb3d13da1f4cbcd1ea7f11440f3e9b03764b186e4ff","transactionIndex":"0x0"},"id":38}.

The difference here seems to be that with that return value, web3.js keeps retrying until there's a receipt.

I don't know what should be done here.
All I can say is that it's unfortunate that web3.js and Parity don't get along well with default settings.

[cgewecke]

@d10r That's the best..thanks so much for figuring all that out.

I don't know what should be done here.
All I can say is that it's unfortunate that web3.js and Parity don't get along well with default settings.

Agree this is not ideal.

In Parity 10550, their engineer says:

If you are running a miner or authority, your node will be maintaining a pending block, which is what queries to the pending block reference - that's currently how that ambiguity plays out in parity, but if we decide to implement that rpc spec EIP I'd imagine the ambiguity should be removed. You certainly shouldn't rely on having access to the pending block as a user or developer though.

The reason you are seeing the ancient block sync reference when looking for a transaction that should be in the pending block is simply because we don't know whether it's a replay of an old transaction in a block we aren't aware of intil ancient sync is complete.

@d10r Is your understanding of the above that this primarily affects people running full Parity mining nodes, e.g it's not something that impacts someone connecting to Kovan over Infura for example?

[d10r]

@d10r Is your understanding of the above that this primarily affects people running full Parity mining nodes, e.g it's not something that impacts someone connecting to Kovan over Infura for example?

That's a good question. Depends if that's specific to the "node signs transaction" use case (which is becoming less relevant and already flagged as being phased out in Parity) or not. I didn't try that yet.
Note that I didn't have my node configured as a miner/authority when capturing the above logs.
I've forwarded the question to the Parity devs in https://github.com/paritytech/parity-ethereum/issues/10550#issuecomment-543080052.

[nivida]

@d10r I will test and fix it on our side asap. It can happen that a transaction is already mined but the receipt is not stored in the DB of the connected node. web3.js should poll for the receipt until it is existing. web3.js will exceed the timeout after 750s over an HTTP connection and over a WebSocket connection after 50 blocks. These two values are configurable in the coming release of web3.js (1.2.2).

[d10r]

@nivida how do you intend to fix it?
Treating an error response like a null response is the only option I see how the reported issue could be solved on web3.js side. I'm however not sure if that's safe. It may cause new issues in other cases. There may be other causes for an error response which may then suffer from web3.js waiting until timeout.
One example coming to my mind: the transaction with the given hash has been replaced by one with a higher gas price. In case the node returns an error when asking for that receipt (don't know if that's the case), it may lead to the application waiting until timeout instead of just reporting the error right away.

Hopefully over at Parity somebody will comment.

[MoMannn]

I have the same problem as @d10r. It happens only with parity, works with geth.
Web3 1.2.4, parity 2.6.5 beta