I am using eth_subscribe with newPendingTransactions and receive a stream of tx hashes. When I use eth_getTransactionByHash to request the transaction bodies for these hashes, I see failure rates of over 40%. Perhaps this is because a new pending tx was received in one part of the Infura backend but isn’t available from the node that is serving my request? Whatever the cause, it makes the pending transaction stream basically unusable.
You might consider providing a websocket subscription of pending transaction bodies rather than just hashes. I’m not sure what use case the original designers had in mind with the hash-only subscription.
I found this thread where spiz reported the same problem:
Hey @pyggie, and welcome to the Infura community! We have definitely considered providing a websocket subscription with the transaction bodies in the past and it’s on our radar as something people want!
As far as getting the transaction bodies, the newPendingTransactions will give a list of all the pending transactions, whereas getTransactionByHash doesn’t return information until the transaction itself gets mined. I would suggest waiting a bit longer to request the details from the new transactions.
Thanks for the reponse, Leiya. In fact, eth_getTransactionByHash does normally return a transaction body for pending transactions, with the blockHash, blockNumber, and transactionIndex fields empty. That’s how you monitor the mempool. And Infura does return a response some of the time, but it has a very high rate of null responses.
I’m glad you are considering a subscription to pending tx bodies. As I said above, a stream of hashes alone is not useful to anybody and I never understood why it was part of the original design.