GetTransactionCount with "pending" doesn't return the correct count

Hey,

My wallet address is 0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22, yesterday I made a transaction with a low Gas price of 0.5 Gwei and that transaction was stuck and not mined for about an hour,

so to fix that, I created another transaction with the same nonce to drop and replace the old stuck tx, and it worked and the transaction was mined correctly.

Right after that, calling getTransactionCount (with "pending" as the block parameter) using the Infura json-rpc API, I keep getting the wrong transaction count for my address (it double counts the replacing transaction and the other transaction), thus using that value for my nonce service creates a nonce gap, making all my future transactions rejected by the network. Also for some reason, Infura keeps counting those failed transactions in the returned value from the RPC call to getTransactionCount.

This behavior is inconsistent with a local geth fullnode running on mainnet, to replicate this bug, try the following call on Infura, and on another fullnode

Using Infura’s json-rpc api:


// using the "pending" block parameter

$ curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params": ["0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22","pending"],"id":1}'

{"jsonrpc":"2.0","id":1,"result":"0x6a"} //0x6a = 106

​

// Using the "latest" block parameter

$ curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID -X POST -H "Content-Type: application:"eth_getTransactionCount","params": ["0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22","latest"],"id":1}'

{"jsonrpc":"2.0","id":1,"result":"0x2"}

Using a local geth fullnode (on mainnet):

> eth.getTransactionCount("0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22", "pending")

2

> eth.getTransactionCount("0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22", "latest")

2

It seems that there’s some caching layer on Infura’s side that doesn’t correctly handle drop and replace transactions, and any further transactions with a wrong nonce, any idea if that’s a problem from my side somehow?

Thanks

1 Like

Thanks for reporting, our team is looking into it. We do have a caching layer on pending transactions and this might be related to that. I’ll post an update here shortly.

Hi there @osagga. We were able to reproduce your issue and have disabled our cache while we roll out a fix. Thanks for reporting and apologies for the inconvenience.

Awesome, thanks for the quick response!

Yeah I can confirm that the API returns the right number now, but that’s probably because the caching is off.

Hi @osagga. After digging into the data more, it looks like we did receive dozens of transactions from your address with the nonce ranging from 3 to 96. Were you trying to send a batch of transactions or were you retrying the transaction with a difference nonce to try to get it unstuck? We want to understand what your actions were so we make sure we understand what fix if any is appropriate. Any further details you can share would be great.

Hey @egalano,

Sorry for the late reply, but yeah my wallet implementation was a bit spammy and kept increasing the nonce by one and retry posting the same transaction multiple times, but it was just getting rejected by the network since the first nonce it tried after the drop & replace was one more than it should be (because Infura double counted the drop & replace transaction), therefore creating a nonce gap. I was only able to fix it by hard-coding the correct nonce.

I hope that explains what happened, let me know if you have any other questions.

1 Like