We’re facing an issue invoking the eth_getTransactionCount method.
Precisely, it seems that invoking the API using “pending” as default block parameter, we get unexpected results.
Moreover, invoking the same API multiple times in a short period of time the result change (and we expect that it remain the same because no transaction has been submitted in the meanwhile).
Following some CURL submitted, each one with the related response.
eth_getTransactionCount: get the number of current Tx.
In rinkeby you have transactions, so you will get that number.
If you spect 0 because you are seeing 0 Tx, maybe you are seeing the mainet or another network.
If you spect 0 because you put the “pending” flag. That means you will get the number of tx considering the pendings as well. The proper way to get the pendings is make a consult like:
#pendingsTx = pendings - latest
Note: If you send a Tx to another node and call the pendigs count of Infura maybe you will get a wrong answer because the Tx is not propagated, you must wait the propagation. The best way is push it to the same node or get a personal counter.
Etherscan shows 4 pending transactions and the last response is correct. So I believe the issue with different nodes have different information. How do we make sure we send transactions and retrieve nonce from the same node?
Hi @yellowred - the end of this thread has some helpful information on nonces and ensuring you’re using the correct one.
If you use the eth_getTransactionCount API, you will be able to see what the next nonce in the sequence should be.
Hi @Leiya_Kenney, in my message above ther is a log showing exactly that eth_getTransactionCount does not show the correct next nonce, but updates it to the correct value after 5 mins. Wonder if there is some caching issue in Infura.
Got it - thanks!
So, getTransactionCount(pending) doesn’t return just the number of pending tx, but mined txs + pending txs - that may be causing some of the confusion.
Hi Leiya! We are aware how that suppose to work. However it does not return the correct number of mined+pending txs at the first try, it requires retry – see the logs above.
Got it. We don’t cache transaction counts for pending data; do you know when the transaction got mined so we can compare? If we have that information, we can dig deeper to figure out whether our transaction count is behind or not.
Geth and Parity/OpenEthereum have different behaviors when calling getTransactionCount("pending"). Geth will count the number of mined and pending TXs immediately after the previous sendTransaction completed. Using the same API, Parity does not immediately include pending TXs in this count; the caller must wait several seconds, ostensibly for the TX to be recorded in the node’s mempool.
To get the correct count using Parity/OpenEthereum, one must call parity_nextNonce. Unfortunately, that produces the following response on Infura:
{'code': -32601, 'message': 'The method parity_nextNonce does not exist/is not available'}
Are there any plans to support this Parity-specific API, or to otherwise offer a facility which can be used to determine the nonce for the next transaction?
Hi @ed.noepel - welcome to the Infura community! If you’re using mainnet, we don’t currently support parity there. As far as your final question, what exactly are you referring to when you mention ‘correct’ count for the nonce? Just want to clarify which nonce value you’re trying to get.
I’d like a call which deterministically returns the sum of mined transactions and submitted transactions, such that calling sendTransaction with this number will produce a new transaction, rather than replacing a previous one.
On Kovan, I can consistently reproduce Parity’s usual behavior of getTransactionCount not counting pending TXes shortly after submission. The Parity issue is documented here, with the fix being "you should probably use parity_nextNonce".
Got it. We’ll look into supporting the API (parity_nextNonce), but it’s not currently supported. You would likely have to do your own nonce management for transactions.
