.on("error") fires even in the absence of errors #2831

justindthomas · 2019-05-21T22:42:48Z

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

The text was updated successfully, but these errors were encountered:

nivida · 2019-05-21T23:52:37Z

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 · 2019-05-22T00:05:57Z

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 · 2019-05-22T00:07:42Z

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

justindthomas · 2019-05-22T00:34:10Z

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 · 2019-05-22T00:52:29Z

Thanks for the test! Will test that asap.

justindthomas · 2019-05-22T23:22:48Z

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 · 2019-05-23T11:20:53Z

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

justindthomas · 2019-05-23T14:50:00Z

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 · 2019-05-29T15:48:19Z

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

joshstevens19 · 2019-05-30T08:26:06Z

@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'."}

#2847 should resolve this yes.

nivida · 2019-05-31T07:50:18Z

Closed because #2487 did resolve this issue.

nivida added the more information needed label May 21, 2019

nivida added Needs Clarification Requires additional input and removed more information needed labels May 22, 2019

nivida closed this as completed May 31, 2019

dforsten mentioned this issue Jul 4, 2019

Set up a hbbft test network in a new repository poanetwork/parity-ethereum#155

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

.on("error") fires even in the absence of errors #2831

.on("error") fires even in the absence of errors #2831

justindthomas commented May 21, 2019 •

edited

nivida commented May 21, 2019

justindthomas commented May 22, 2019

nivida commented May 22, 2019

justindthomas commented May 22, 2019

nivida commented May 22, 2019

justindthomas commented May 22, 2019

nivida commented May 23, 2019

justindthomas commented May 23, 2019 •

edited

justindthomas commented May 29, 2019

joshstevens19 commented May 30, 2019 •

edited

nivida commented May 31, 2019

.on("error") fires even in the absence of errors #2831

.on("error") fires even in the absence of errors #2831

Comments

justindthomas commented May 21, 2019 • edited

Description

Expected behavior

Actual behavior

Steps to reproduce the behavior

Error Logs

Versions

nivida commented May 21, 2019

justindthomas commented May 22, 2019

nivida commented May 22, 2019

justindthomas commented May 22, 2019

nivida commented May 22, 2019

justindthomas commented May 22, 2019

nivida commented May 23, 2019

justindthomas commented May 23, 2019 • edited

justindthomas commented May 29, 2019

joshstevens19 commented May 30, 2019 • edited

nivida commented May 31, 2019

justindthomas commented May 21, 2019 •

edited

justindthomas commented May 23, 2019 •

edited

joshstevens19 commented May 30, 2019 •

edited