Web3.js: .on("error") fires even in the absence of errors

[justindthomas]

Description

Using: 1.0.0-beta.55

Calling sendSignedTransaction, only the "transactionHash" and "error" handlers are firing, "receipt" is never triggered. The "error" handler is firing immediately even when there are no errors and the transaction is ultimately (and timely) mined.

Expected behavior

Config.web3.eth.sendSignedTransaction("0x" + serializedTx.toString("hex")) .on("transactionHash", (hash: any) => { ... }) .on("receipt", (receipt: any) => { ... }) .on("error", (error: any) => { ... });
. . . should result in the "transactionHash" function being fired upon submission, followed by the "receipt" when the transaction is mined.

Actual behavior

The "transactionHash" is sent immediately, followed quickly by an "error" with an object that looks like:

{"error":{},"receipt":false,"confirmations":0,"confirmationChecks":0}

The "receipt" handler is never triggered. The transaction is subsequently successfully mined.

Steps to reproduce the behavior

See above.

Error Logs

This is what it looks like in my logs. "dissolve" is just a standard contract call that flips a bit to indicate that the contract is no longer valid.

22:27:41 0|ts-node | 2019-05-21 22:27:41,067 INFO [endowment] DISSOLVE CONTRACT: 0x6e58B2dc11019bB49Eee0591428f869A22491a93 22:27:41 0|ts-node | ::ffff:10.48.0.32 - - [21/May/2019:22:27:41 +0000] "POST /api/friendowment/dissolve HTTP/1.1" 200 22 "-" "Apache-HttpClient/4.5.6 (Java/1.8.0_212)" 22:27:41 0|ts-node | 2019-05-21 22:27:41,683 INFO [processor] contract_dissolution submitted: 0xc0f3d47fb6a7ec6e8ad4981ea5ceb30be4aec9f185cdf0c6bcafcfe210313eb0 22:27:42 0|ts-node | 2019-05-21 22:27:42,735 INFO [processor] ERROR: {"error":{},"receipt":false,"confirmations":0,"confirmationChecks":0} 22:27:42 0|ts-node | 2019-05-21 22:27:42,794 INFO [processor] transaction failed: contract_dissolution e8153eef-3d26-4d38-97d1-8d566cfe4bf1

Versions

• web3.js: 1.0.0-beta.55
• nodejs: 11.11.0
• ethereum node: Parity v2.2.11-stable

[nivida]

Thanks for opening this issue. Did you configure the transactionConfirmationWorkflow as described in the documentation and mentioned in the release notes here on GitHub? The default value is 24 this means it has to wait 24 blocks until the receipt event gets triggered.

[justindthomas]

I haven't! I'll take a look at that.

Regardless, 24 blocks is about 6 minutes, right? Over the course of several hours, I see results from the "transactionHash" and "error" triggers, but nothing for "receipt". My assumption was that the immediate (seemingly spurious) call to "error" might be stopping any further processing.

[nivida]

Thanks for the quick answer. I will test it too asap.

[justindthomas]

I updated with:

`````
const options = {
transactionBlockTimeout: 50,
transactionConfirmationBlocks: 6,
transactionPollingTimeout: 480 }

export let web3 = new Web3(new Web3.providers.HttpProvider(nconf.get("ETHEREUM_NODE")), null, options);
`````

The behavior is unchanged; "transactionHash" followed immediately by "error" with no "receipt". The transaction is then successfully mined.

`````

date
Tue May 21 17:32:11 PDT 2019
kubectl logs . . . | grep usdf_transfer
00:28:04 0|ts-node | 2019-05-22 00:28:04,546 INFO [processor] usdf_transfer submitted: 0xb884a2161697c3b08fb8bf2116d70b64ed11424d1cc6fb0dba3f4d75e77d6bc1
00:28:05 0|ts-node | 2019-05-22 00:28:05,638 INFO [processor] transaction failed: usdf_transfer 83cc1ca0-6e91-4f22-a7f8-23535ae7470c
`````

[nivida]

Thanks for the test! Will test that asap.

[justindthomas]

As a test, I changed things around to use just ".then" instead of the multiple ".on" calls:

Config.web3.eth.sendSignedTransaction("0x" + serializedTx.toString("hex")) .then((receipt: any) => { ... });

That resulted in these errors:

{ error: Error: Node error: {"code":-32602,"message":"Invalid params: invalid type: null, expected a block number or 'latest', 'earliest' or 'pending'."} at Function.validate (/srv/friendowment/node_modules/web3-providers/dist/web3-providers.cjs.js:114:18) at HttpProvider._callee$ (/srv/friendowment/node_modules/web3-providers/dist/web3-providers.cjs.js:710:61) at tryCatch (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:45:40) at Generator.invoke [as _invoke] (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:271:22) at Generator.prototype.(anonymous function) [as next] (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:97:21) at asyncGeneratorStep (/srv/friendowment/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24) at _next (/srv/friendowment/node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9) at processTicksAndRejections (internal/process/task_queues.js:86:5), receipt: false, confirmations: 0, confirmationChecks: 0 } { error: Error: Node error: {"code":-32602,"message":"Invalid params: invalid type: null, expected a block number or 'latest', 'earliest' or 'pending'."} at Function.validate (/srv/friendowment/node_modules/web3-providers/dist/web3-providers.cjs.js:114:18) at HttpProvider._callee$ (/srv/friendowment/node_modules/web3-providers/dist/web3-providers.cjs.js:710:61) at tryCatch (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:45:40) at Generator.invoke [as _invoke] (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:271:22) at Generator.prototype.(anonymous function) [as next] (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:97:21) at asyncGeneratorStep (/srv/friendowment/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24) at _next (/srv/friendowment/node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9) at processTicksAndRejections (internal/process/task_queues.js:86:5), receipt: false, confirmations: 0, confirmationChecks: 0 } { error: Error: Node error: {"code":-32602,"message":"Invalid params: invalid type: null, expected a block number or 'latest', 'earliest' or 'pending'."} at Function.validate (/srv/friendowment/node_modules/web3-providers/dist/web3-providers.cjs.js:114:18) at HttpProvider._callee$ (/srv/friendowment/node_modules/web3-providers/dist/web3-providers.cjs.js:710:61) at tryCatch (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:45:40) at Generator.invoke [as _invoke] (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:271:22) at Generator.prototype.(anonymous function) [as next] (/srv/friendowment/node_modules/@babel/runtime/node_modules/regenerator-runtime/runtime.js:97:21) at asyncGeneratorStep (/srv/friendowment/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24) at _next (/srv/friendowment/node_modules/@babel/runtime/helpers/asyncToGenerator.js:25:9) at processTicksAndRejections (internal/process/task_queues.js:86:5), receipt: false, confirmations: 0, confirmationChecks: 0 } abort({"error":{},"receipt":false,"confirmations":0,"confirmationChecks":0}). Build with -s ASSERTIONS=1 for more info.

Based on the error messages I thought I might need to specify the "defaultBlock" in the options, so I went ahead and did that like this:

const options = { defaultBlock: 'latest', transactionBlockTimeout: 50, transactionConfirmationBlocks: 6, transactionPollingTimeout: 480 }

Unfortunately that didn't change anything and the system generates those same errors even with the defaultBlock set.

[nivida]

Thanks for the additional information! Could you reference a GitHub repository for having a deeper insight in your code?

[justindthomas]

Sure. I just added the TypeScript source files here (I'm not sure that the history is clean on my main repository and haven't opened it up): https://github.com/justindthomas/issue-2831/blob/master/processor.ts#L177

A lot of that code hasn't been touched in quite a while (a year or so) and I do know some of it is ineffective right now (e.g., the pattern matching on the error messages). My plan is to fix that once I get this issue sorted out.

[justindthomas]

Could this be related to #2847? The reference to Parity and the getBlock call generating errors seem relevant.

[joshstevens19]

@justindthomas @nivida Yes your error from your logs seems to be the invalid eth_getBlockByNumber JSONRPC calls due to parity sending the receipt back before its mined unlike geth which web3 does not account for.

Your error is exactly the error which would be thrown by the nodes if this happened:

 Error: Node error: {"code":-32602,"message":"Invalid params: invalid type: null, expected a block number or 'latest', 'earliest' or 'pending'."}

https://github.com/ethereum/web3.js/pull/2847 should resolve this yes.

[nivida]

Closed because #2487 did resolve this issue.