4

I am trying to use web3 or JSON-RPC to get a list of pending transactions.

The web3 API docs say that a call to web3.eth.getBlock('pending') will return a structure showing the block number and hash to be null. The answer to this question agrees and says that block.transactions will have pending transactions. But I see non-null values for the number and hash fields that match the latest block and a list of transactions that were included in that block. In fact, web3.eth.getBlock('pending') and web3.eth.getBlock('latest') return the same result. For example, when running a local parity node (Parity/v1.4.7-beta-f2058bd-20161227):

> let Web3 = require('web3');
> let web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
> blockL = web3.eth.getBlock('latest');
> blockP = web3.eth.getBlock('pending');
> [blockL.number, blockL.hash]
[ 2971275, '0x2187511e60d49a5ed081ccc31ee4f76365727254e9001f4b563c47cee457ed3f' ]
> [blockP.number, blockP.hash]
[ 2971275, '0x2187511e60d49a5ed081ccc31ee4f76365727254e9001f4b563c47cee457ed3f' ]

I tried making the JSON-RPC call directly and also got the latest block, not information about the pending one:

$ curl -s -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["pending",false],"id":0}' localhost:8545
  { "result" : {
       ... ,
       "number" : "0x2d4c56", 
       ...
       "hash" : "0xb0d47255dbeae836384321b1141ae221254fa7ee4ded07f3d49afb875f05a44e"
       ... }
  }

I also tried using an Infura RPC node and got similar results.

Do I misunderstand what pending is supposed to mean? Is there another way I should use web3 or JSON-RPC to get the list of pending transactions?

(When I use web3.eth.filter('pending') I do see pending transactions as they arrive at my node, but that is different from asking for the current pending set.)

Community
  • 1
pyggie
  • 558
  • 5
  • 10

3 Answers3

5

This answer suggests to me that web3.eth.getBlock('pending') is only relevant if you are mining. Are you?

If not, then yes.. returning the currently mined block seems to be expected behaviour.

Community
  • 1
Thomas Clowes
  • 4,385
  • 2
  • 19
  • 43
  • No, I was not mining. I saw that answer, but as I reread it now it seems specific to the geth built-in console, not the web3/RPC interface, as it refers to non-web3 accessors such as eth.pendingTransactions. The web3 and JSON-RPC docs do not suggest local mining is required to see pending transactions, and I do see them with web3.eth.filter('pending'). My motivation is to monitor the lifecycle of transactions created by a Dapp. I'd like to compare the list of transactions I have attempted to send with those that are currently pending or mined. – pyggie Jan 12 '17 at 15:59
  • This answer by Péter Szilágyi suggests pending is useful to a UI that wants to show the progress of a transaction. I guess I can always call web3.eth.getTransaction() on each of the transactions of interest. If it is pending, the .blockNumber will be null. – pyggie Jan 12 '17 at 16:22
0

An answer to this question in 2023:

This is not correct. Seems like a bug in Parity. Now all clients return different information for the "pending" and "latest" blocks.

  • "latest" - for the latest mined block
  • "pending" - for the pending state/transactions which is likely to be mined in the next block.
Wuzhong - Chainstack DevEx
  • 1,424
  • 2
  • 10
0

Your Parity node will return different pending block only when one of the mining or sealing(--force-sealing) modes turned on. This forces node to build pending blocks and respect em on API calls.

k06a
  • 3,016
  • 2
  • 21
  • 35