Transaction receipt not generated after a long time

Bugs
1

Hi all.

I’ve experienced (only once) this strange behavior:

Our code, that’s using web3j library, create and successfully send a transaction (in test-net Rinkeby) that has been mined but the related transaction receipt was not generated.

Precisely, I’ve found this message inside the application logs:

org.web3j.protocol.exceptions.TransactionException: Transaction receipt was not generated after 600 seconds for transaction: 0x2d9e55e81e1aadf2cd5457eab1e3ecccad0458b2f15fd652cd034974764eb806

Follows a section of the stack trace:

2019-08-22 13:19:07.011 ERROR 20717 — [nio-8080-exec-9] c.n.e.b.s.i.b.BaseServiceImpl : org.web3j.protocol.exceptions.TransactionException: Transaction receipt was not generated after 600 seconds for transaction: 0x2d9e55e81e1aadf2cd5457eab1e3ecccad0458b2f15fd652cd034974764eb806
at org.web3j.tx.response.PollingTransactionReceiptProcessor.getTransactionReceipt(PollingTransactionReceiptProcessor.java:51)
at org.web3j.tx.response.PollingTransactionReceiptProcessor.waitForTransactionReceipt(PollingTransactionReceiptProcessor.java:29)
at org.web3j.tx.TransactionManager.processResponse(TransactionManager.java:72)
at org.web3j.tx.TransactionManager.executeTransaction(TransactionManager.java:51)
at org.web3j.tx.ManagedTransaction.send(ManagedTransaction.java:87)
at org.web3j.tx.Contract.executeTransaction(Contract.java:284)
at org.web3j.tx.Contract.create(Contract.java:326)
at org.web3j.tx.Contract.deploy(Contract.java:355)
at org.web3j.tx.Contract.lambda$deployRemoteCall$7(Contract.java:449)
at org.web3j.protocol.core.RemoteCall.send(RemoteCall.java:30)

As you can see at this link the transaction has been correctly mined.

I’m aware that the timout is related to the web3j implementation but I’m concerned about the long waiting time that, probably, is caused by Infura.

I’ve also some questions:

  • How long could take to get a transaction receipt?
  • Are there any kind of timeout from Infura?
  • Making the assumption that this behavior, for some reason, cannot be avoided, how do you suggest to manage this exception?

Every hint/suggestion/clarification is really appreciated.

Thanks!

2

I’m concerned about the long waiting time that, probably, is caused by Infura.

The timeout of 600 seconds is configured in web3j. 40 attempts every 15 seconds = 600 secs. web3j/core/src/main/java/org/web3j/tx/TransactionManager.java at 7eab3d5752fb661f58df037a11677f330b8e1117 · web3j/web3j · GitHub

public static final int DEFAULT_POLLING_ATTEMPTS_PER_TX_HASH = 40;
public static final long DEFAULT_POLLING_FREQUENCY = DEFAULT_BLOCK_TIME;
  • How long could take to get a transaction receipt?

A transaction receipt is only generated once a transaction is mined. This is not controlled by Infura but by the miners on the target network and the congestion of the pending transaction pool. Im surprised that your transaction timed out after 10 minutes since this was on the rinkeby network where I would expect it to get mined in under a minute. Are you consistently encountering this behavior on rinkeby or was it just this one transaction where you saw this?

Are there any kind of timeout from Infura?
No. The polling from web3j is where the timeout would be coming from. getTransactionReceipt is a stateless request and does not require a persistent connection. If the transaction receipt requested is not yet available you will get a null response.

  • Making the assumption that this behavior, for some reason, cannot be avoided, how do you suggest to manage this exception?

This depends on the logic of your application. Is this a critical transaction in your workflow? If so, you would likely retry the transaction with a higher gas price.

Hope this helps.

3

Marco,

I can’t really tell what was happening in web3j at the time you ran into this behavior but can confirm our endpoint returns the correct data:

curl -L https://rinkeby.infura.io/v3/${PROJECTID} -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params": ["0x2d9e55e81e1aadf2cd5457eab1e3ecccad0458b2f15fd652cd034974764eb806"],"id":1}' | jq .

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "blockHash": "0x03ad5245d5b168ca49dd1045aa2ff9cf275592d0ed1b9c6c9f0718f703556c84",
    "blockNumber": "0x4b9e70",
    "contractAddress": "0x3c965fcabeffeb9b0ae21aee2dd7599a35e28d28",
    "cumulativeGasUsed": "0x55d0dd",
    "from": "0x51e617c0b056edfb5f1fe29a7d93b505f6d07c97",
    "gasUsed": "0x27097e",
    "logs": [
      {
        "address": "0x3c965fcabeffeb9b0ae21aee2dd7599a35e28d28",
        "blockHash": "0x03ad5245d5b168ca49dd1045aa2ff9cf275592d0ed1b9c6c9f0718f703556c84",
        "blockNumber": "0x4b9e70",
        "data": "0x",
        "logIndex": "0xc",
        "removed": false,
        "topics": [
          "0xe771f107c07e5c35bf8c1484bf79fc9cb178b25d039702580305a2dd453936c9",
          "0x00000000000000000000000092eda5a51914edadf86441bb7d7ffdeab73e213d"
        ],
        "transactionHash": "0x2d9e55e81e1aadf2cd5457eab1e3ecccad0458b2f15fd652cd034974764eb806",
        "transactionIndex": "0xd"
      },
      {
        "address": "0x3c965fcabeffeb9b0ae21aee2dd7599a35e28d28",
        "blockHash": "0x03ad5245d5b168ca49dd1045aa2ff9cf275592d0ed1b9c6c9f0718f703556c84",
        "blockNumber": "0x4b9e70",
        "data": "0x0000000000000000000000000000000000000000000000000853a0d2313c0000",
        "logIndex": "0xd",
        "removed": false,
        "topics": [
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
          "0x0000000000000000000000000000000000000000000000000000000000000000",
          "0x0000000000000000000000003c965fcabeffeb9b0ae21aee2dd7599a35e28d28"
        ],
        "transactionHash": "0x2d9e55e81e1aadf2cd5457eab1e3ecccad0458b2f15fd652cd034974764eb806",
        "transactionIndex": "0xd"
      }
    ],
    "logsBloom": "0x40000000000000000000008000000000000000000000040000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000004000000000008000010000000000000000010000000000000000000000000020000000000000000000800000000000000000000000010000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000001000000000080000000000000000000000000000000000002100000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000040000000000000000",
    "status": "0x1",
    "to": null,
    "transactionHash": "0x2d9e55e81e1aadf2cd5457eab1e3ecccad0458b2f15fd652cd034974764eb806",
    "transactionIndex": "0xd"
  }
}
4

Thanks for the clarification @egalano and @Ryan_Schneider.

Yes, I was aware about the web3j behavior, the only thing that made me uncertain was the long time encountered.

Anyway, luckily happened only once.

I will improve my code in order to take into account the possibility to retry the transaction with an higher gas price.

Thanks.

5

@marco sorry I didn’t draw this conclusion sooner, but I just realized the timing of your issue looks like it could’ve coincided w/ the rinkeby signer outage:

So that might explain why your tx timed out. Maybe by the time you looked on etherscan it was already back up? What timezone is 2019-08-22 13:19:07.011 in, UTC? Looking at our logs I see rinkeby was not propagating new blocks from 2019-08-22 09:43:00 UTC to 2019-08-22 11:21:00 UTC, so if your timestamp is UTC it’s probably not related, but if it’s a local timezone there’s a good chance it was.